Use AI-powered review

Este contenido aún no está disponible en tu idioma.

This guide shows you how to have reviewer agents review a pull request and how to publish the result to GitHub.

Start an AI review

Open the PR and go to its Overview tab
Open the ⋯ overflow menu in the action row and choose Ask AI

The item only appears while the PR is open — it is a pre-merge action. The same button is offered as Ask AI on the Review tab’s empty state, before any review exists.

Control Center starts the seeded pr_review pipeline and opens the PR’s Review tab so you can watch it. The pipeline:

Opens the PR’s own review space, whose isolated worktree has the PR checked out at its head
Fans out the reviewers for the workspace’s review level — three by default (the seeded qa, architect and engineer agents, in parallel). There is no language or domain detection
Has the lead (CEO) agent consolidate their findings into a walkthrough
Finalizes: sorts the findings into consensus buckets and computes the verdict. When the association reaches awaiting approval, Publish to GitHub appears on the Review tab

How deep the review goes is the workspace’s review level — light (one reviewer), balanced (three, the default) or thorough (all five, adding the security and performance specialists) — set at Settings → Workspace → General, on the Workspace policy card. A lighter level files just as many findings; it reports fewer of them front and centre.

All the reviewers post into the PR’s single review space, which is what makes their findings comparable. See AI review for how the pieces fit together.

pr_review ships with a manual trigger only. To have it fire on every published PR, add a trigger yourself — see Dispatch reviewer agents. You can also start one from GitHub itself, no pipeline trigger needed: mention the server’s bot on the PR or add the ai-review label — see Talk to Control Center from a GitHub PR.

If a toast says a review is already running for this pull request, one is already in flight; stay on the Review tab or open Pipelines to find it.

Read the findings

Reviewers record findings as review nodes in the review space. Each carries:

Field	Description
Kind	`bug`, `suggestion`, `recommendation`, `question` or `ticket`
Priority	P0 (critical) → P3 (nit)
Category	`security`, `stability`, `data_integrity`, `correctness`, `performance` or `maintainability`
File and line	Where the finding is anchored
Original code	The code the finding is about
Suggested code	The proposed fix
Confidence	How confident the reviewer is
Status	`open` → `consensus-ready` → `resolved` or `dismissed`

A finding only reaches consensus-ready once a peer reviewer confirms it. An agent cannot confirm its own finding, so a single reviewer’s opinion never graduates on its own.

The Review tab shows the findings list, filterable by kind and status, with a toggle for dismissed findings, beside the artifact the consolidating agent published. The deterministic view — cohorts, the multi-axis dashboard, contract and visual diffs — is computed server-side but has no surface in the app; see Review compute for what the pass produces.

Check the disagreements panel

When two reviewers anchor findings to the same file and line but rate them very differently — priorities two or more levels apart, or one calls it a bug while the other calls it a suggestion — a disagreement panel appears above the findings list. Read those first: they are where the reviewers’ opinions diverge and your judgement is worth the most.

Read the verdict

When the lead agent finalizes, it computes a verdict:

Verdict	Meaning
Ship	Nothing blocking found
Hold	Issues that should be addressed before merge
Block	Critical issues that must be fixed

The verdict carries an aggregate confidence score and per-priority finding counts.

The review axes then fold into it and they can only make it more severe. A gated axis that fails forces Block; a gated axis that could not complete (partial) or could not run at all (unavailable) forces at least Hold. Absence of evidence never clears a gate.

Publish the review to GitHub

Publishing is a separate, deliberately user-gated step. The pr_review pipeline keeps the review in Control Center; it does not post to GitHub.

On the Review tab, wait until Publish to GitHub appears
Press Publish to GitHub

Control Center sends one GitHub review. Findings already resolved or dismissed are skipped. The button includes every remaining open finding and, on Ship, submits APPROVE. (The MCP tool publish_review_to_github still defaults to peer-confirmed findings only and does not approve unless you pass approve_on_ship.) Those that carry a file and line anchor become inline comments; everything else folds into the summary body, each with a “— Control Center AI review” footer so the source is unambiguous. A Block verdict is submitted as REQUEST_CHANGES; Hold as COMMENT; Ship as APPROVE from this button. A toast then reads Published. The review is posted under the server’s app identity.

If GitHub rejects an inline anchor because the line is not part of the diff, the whole review is re-sent with every finding folded into the body, so nothing is silently dropped.

Other built-in pipelines do post to GitHub directly: cross_review, pr_triage, ticket_to_pr and pre_merge_gate each end in a comment step. Only pr_review holds its output back for you.

Dispatch reviewers yourself

For control over which roles review the PR and which files each one looks at, use the dispatch_reviewers MCP tool inside an existing review space, or add reviewer nodes to a pipeline. Both paths, with the tool’s exact signature, are in Dispatch reviewer agents.