What are deep reviews?

A deep review uses a separate generative model and review engine to investigate the change independently of the coding agent. Deep reviews run in minutes and can start before a PR exists. On a pull request, they work like a traditional reviewer. Doomer brings together the pull request, related code, available project context, and your team’s review history to identify problems worth investigating before merge.

The result is a review your team can work through, with findings, supporting evidence, and an explanation of how the change relates to its intended behavior.

How a deep review comes together

Starting a deep review brings several kinds of context together in parallel: collecting sources, determining intent, identifying attack paths, and inspecting code provenance.

That context informs the independent investigations. The review engine then reviews the findings and their evidence before posting feedback to the pull request. Available sources and coverage gaps remain visible alongside the results.

From a diff to an investigation

A change can look reasonable in isolation while breaking a caller, leaving a requirement incomplete, or exposing a path through several parts of the application. Deep reviews examine those relationships.

Doomer reviews the recorded base and head commits, investigates potential issues using repository context, and checks concerns before presenting findings. Your review settings select the review passes and control which findings are posted to GitHub.

Context the review brings together

The available context depends on the repository, connected integrations, and enabled features. The review page shows the sources it used and any gaps in retrieval.

Linked requirements and suggested work retain their source labels. A search result can suggest a connection to investigate, while an explicitly linked issue provides the work the author associated with the pull request. Coverage details make it possible to see what was retrieved and what remains unavailable.

Intent connects the code to the goal

When intent capture is enabled, Doomer synthesizes a short statement of purpose and the constraints supported by the pull request, linked sources, and comments in the changed code. The Intent section presents that synthesis alongside the underlying source evidence.

This gives the review a way to examine whether the implementation delivers the requested behavior. A change might be internally consistent but omit an acceptance criterion, handle the wrong case, or conflict with a requirement in a linked story. When available, story-alignment results describe how the change relates to that work.

You can clarify expected behavior on the review page. If the saved intent changes, Review updated intent can request a new review against that context. See the intent guide for availability and the conditions for rerunning. Intent and provenance.

Attack paths explain how findings connect

An individual finding identifies a concern. An attack path explains a possible route from an entry point, through the affected code, to an impact.

When a completed review produces an attack-path brief, it includes the entry point, the path through the application, the possible impact, the finding that supplies evidence, and the uncertainty that remains. This helps you follow the reasoning across components and decide where to investigate or add a check.

For example, an invoice-export change might accept an account ID from a request, pass it through a handler, and use it in a database query. If a finding identifies a missing ownership check, an attack path can connect the request input to the query and explain the potential exposure of another account’s invoices. The brief keeps the evidence and remaining assumptions visible alongside that route.

Provenance shows the recorded authorship context

When Git AI notes are available, the project review page can show which coding agents and models were recorded for commits in the pull request. It also shows coverage, including commits whose notes could not be read. Missing notes leave authorship unknown.

Provenance appears separately from intent and findings so your team can inspect how the change was produced alongside what it does.

A review your team can act on

Doomer posts a GitHub check and review comments. Findings on changed lines appear on the diff, while other findings appear in the review body. The project review page brings the investigation together with Intent, Sources, Findings, Attack paths, and available Code provenance.

Start with the intended behavior, inspect the evidence behind a finding, and follow any attack path that helps explain its impact. Your team can discuss findings, make fixes, and request another review. Project settings control posting thresholds and summaries, while Stampy Stamp provides optional approval and merge rules.

Quick reviews complement this workflow by supplying early leads while you or your coding agent are still editing. A deep review provides another investigation point when you are ready to assess the complete change.

Get started

Connect GitHub and enable a repository, then add the issue sources that describe your team’s work. Set up deep reviews · Connect review context · Configure reviews.