Checks and /doomer run

Hosted reviews show up as a GitHub App check named Doomer. They are not a job in .github/workflows.

Check states

Doomer creates the check on the head commit as soon as the review is queued. The worker moves that same check to in progress when it claims the job.

Branch protection is yours to configure. Doomer does not mark the check required. If you require the Doomer check, a neutral result is still a completed check with findings; a failure means the review itself failed.

When a new hosted review starts, Doomer dismisses its previous GitHub approvals on the pull request, including for same-commit reruns and /doomer run. Human approvals and other bots’ approvals are preserved. Stampy Stamp can approve again after the new review completes and passes its checks. If GitHub cannot dismiss the old approval, the review waits for a retry. Review-only runs requested on draft pull requests are the exception: they do not dismiss approvals or enter Stampy evaluation.

GitHub Re-run queues that App check again. Doomer revalidates the installation, the repository, and that the project is still entitled, then reviews the same head.

A later successful review on a new commit resolves older App-authored threads when their finding identity is gone from the new result. The same finding on the new commit stays open. Resolving threads needs the installation to approve Contents: write. Until then, the new review still posts and the check reports that older conversations could not be updated.

/doomer run

Comment /doomer run on an open pull request to queue the latest hosted review for the current head.

Doomer accepts the command from:

• a repository owner
• an organization member
• a repository collaborator

Contributor comments and other untrusted users are ignored, with no review queued. When Doomer recognizes the command, it replies. The reply says the review was queued, or that a review for that head is already queued or running.

The repository must be turned on in Repos, the pull request must be open, and the project must be the single hosted-inference project for that installation. /doomer run works even when Automatic reviews is unchecked for that repository, including on a PR that has never been reviewed, has new commits, or is still a draft. A draft run applies the normal posting threshold and creates an informational COMMENT review, but it does not dismiss approvals, resolve older review conversations, approve, or merge. Marking the PR ready queues a normal review for the same head when automatic reviews are on.

Other /doomer commands

/doomer rerun requests a fresh, full review of the PR. When stateful reviews are enabled, /doomer run and GitHub Re-run respect the previous review state and assess later changes and their effects. Use /doomer rerun when you explicitly want the entire PR reassessed. Earlier review history is preserved, and subsequent stateful reviews use the completed full review as their baseline. If a review is already queued or running, wait for it to finish before requesting another full review. The same permissions and draft review-only restrictions apply to both commands.

Stateful re-reviews may read unchanged files to trace the effects of new changes. New findings must be connected to those changes; earlier conversations close only when a fix is confirmed. Stateful reviews are experimental and off by default. When enabled, the initial full review and /doomer rerun give each adversary that returns findings one additional independent pass over the full PR. Adversaries with no findings are not repeated. Both passes are combined and deduplicated before publishing; a failed second pass prevents the review from establishing a new baseline. Later stateful reviews use a single pass.

/doomer no-approve disables automatic approvals and automatic merging for this PR, including future commits and reruns. The command itself leaves existing approvals in place. Reviews continue; when a subsequent review starts, Doomer dismisses its previous approvals and does not approve again while automatic approval is disabled.

Comment /doomer help to list the supported commands, including /doomer rerun for a fresh, full review. /doomer hi and other unknown /doomer commands also return this help with a playful greeting. The greeting is generated by an LLM when available, with a friendly fixed reply if it is unavailable. Unknown commands do not start reviews or change settings. These replies use the same open-PR and trusted-commenter rules as /doomer run; bot comments, edited comments, and ordinary issues are ignored.

What does not start a review

• Installing or enabling the App, by itself. Existing open pull requests wait for a later event, /doomer run, or the periodic reconcile.
• Pull request events or periodic reconciliation when Automatic reviews is off for the repository. /doomer run and explicit reruns still work.
• A comment that is not /doomer run from an allowed user.
• A synchronize event whose head is already queued or running. Duplicate deliveries collapse to one job.
• Closing the pull request or changing between draft and ready state. An in-flight run is cancelled before it publishes comments if the head, base, or review mode no longer matches. Use /doomer run to start a review-only run while draft.

Workers also scan repositories with automatic reviews enabled about every 15 minutes. A missed opened, reopened, ready_for_review, or synchronize webhook converges to the same job and the same queued check.

Where to read the result

The check and the GitHub review are the result on the pull request. The project page /review/<project>/<owner>/<repo>/<number> adds intent, sources, withheld findings, attack paths, provenance, and Stampy decisions. The run record is linked from that page and listed at /team/<namespace>/runs.