DUUMBI Loop intent to review.
A GitHub-connected DUUMBI workflow for turning GitHub repository issues and pull requests into intake, specs, review targets, and implementation evidence. This route opens the production Loop service and does not claim the full DUUMBI Loop product is complete.
- Primary path
- GitHub repos
- Adapters
- GitHub first
- Auth
- DUUMBI SSO
loop app - 1 Login
Sign in with DUUMBI SSO
Open the Loop app through the central auth.duumbi.dev issuer before any repository data is available.
- 2 GitHub
Connect a repository provider
Use the Providers screen to install the DUUMBI GitHub App and keep tokens server-side.
- 3 Repos
Choose the repositories to use
Pick available GitHub repositories from the server-side repository list and enable only selected repos.
- 4 Loop
Run intake, spec, and review
Drop @duumbi intake / spec / review / closure comments in GitHub to create tracked artifacts and review evidence.
DUUMBI chooses the route behind stable labels.
Users see DUUMBI-owned model labels. DUUMBI decides when a provider or model is appropriate behind the scenes, while administrators control which labels and provider routes are usable for their organization.
Fast
Balanced
Deep Research
Strict Review
Private/BYOK
GitHub is the first production repository path.
DUUMBI Loop connects to GitHub repositories through the Providers
page. A team can register a repository, add a comment such as
@duumbi review,
and follow the run state, workflow step, artifacts, and review result
in the Loop UI.
- GitHub is the required provider path for the production minimum.
- GitLab remains out of scope until the GitHub path is proven.
- Raw provider and model SKUs are not user-facing choices.
- Provider access is configured by admins and used indirectly through DUUMBI labels.
- Central login is owned by auth.duumbi.dev.
Admins monitor organization runs, route decisions, audit evidence, and provider access. Customers continue to use DUUMBI-owned model labels instead of choosing raw provider or model SKUs.