Reviews

Review the delivered result against the Task's acceptance criteria before treating a successful Run as a completed job. An Agent review can help find gaps, while the final reviewer remains responsible for the decision.

Check repository changes before delivery

Eligible Engineering tasks with an agent implementer and a connected repository receive internal code review when the check is available. The first step checks completed changes against enabled repository rules before the agent submits outcome evidence. Other categories, unclassified tasks, human implementations, and workflow-owned work retain their existing review paths.

When no rule finding blocks submission, a task whose approved plan has high sensitivity or a Critical review level also receives adversarial review. Two independent reviewers examine the changed files together for defects such as a broken caller, a duplicate charge on retry, or a test that passes for incorrect behavior. Tasks without an approved plan do not receive this second step.

A defect raised by both reviewers becomes a blocking finding. A claim from one reviewer remains a non-blocking potential finding. Each claim includes concrete reproduction steps so the implementer can check it against the actual code before fixing it.

The task stays In progress while the implementer fixes blocking findings or dismisses a false positive with evidence. After changes, later clean rule scans recheck open adversarial findings rather than repeat the independent hunt. You can inspect the claims, reproduction steps and agreement in Task history and alongside the review decision in Inbox.

An unavailable reviewer or a change beyond the reviewers' context window skips the additional review and leaves the rule-scan result intact. That skip does not establish that adversarial review passed. A failed or incomplete review never counts as a pass. The CLI reference explains terminal use, which requests both steps without requiring a task plan.

The scan can run while a pull request is still a draft, before activation or source-host approval. Outcome checks begin at evidence-aware submission after the required delivery checks. Internal code review never replaces those checks, fresh-session pre-review, or your final review decision.

Evaluate evidence

Read the summary, follow important source links, and inspect the attached files or Library documents. Check what is missing or contradicted, not only whether the answer sounds confident. Use Browser use when recorded browser actions matter to the result.

For a new responsibility, check awkward cases deliberately: conflicting figures, an unanswered question, a request outside the brief, or an outdated source. For familiar internal drafts, you may spot-check established parts while examining changed or consequential claims closely.

An Agent's submitted evidence can receive an outcome check against each acceptance requirement before review. Task and Inbox show Pass, Fail, or Uncertain beside the original requirement. Work still being checked shows Checking. The result stays in Task history even when the move to review is rejected. A recorded result marked Outdated did not hand the Task to its reviewer and does not establish that the work passed review. Repository work still needs its required delivery checks before that handoff.

The quick check inspects the submitted file excerpts, change diff, or exact Library document versions. For repository work, omitting the diff selector automatically includes the complete patch of committed source changes from the common ancestor with the locally available default branch to the captured current commit. An Agent can opt out by setting diff to null, or choose an explicit base and head instead. The CLI reference explains the selectors and local default-branch selection.

Automatic collection runs only at the repository worktree root. It does not search directories, collect uncommitted or untracked changes, fetch history, or run tests, and it does not depend on a pull request or CI. If local history is missing, has no commits, or has no single common ancestor, the other evidence remains available without an automatic diff. A summary or empty patch alone cannot establish the result. Large evidence is checked in sections, with related source evidence checked together when a requirement spans sections. Size increases the work needed rather than skipping the check or truncating the evidence.

A failed requirement or missing implementation evidence stays with the implementer. An uncertain requirement needing human judgment, such as visual approval, can continue to full review. Neither a passing check nor full-review routing replaces the final review decision.

Interrupted checks retain their progress. Routine Run keep-alives do not make unchanged work outdated. Changed requirements, evidence, execution or authority still prevent a stale handoff.

Handle the review in Inbox with its decision context and actions. Open Task history when you want to investigate a particular result or compare earlier work, not because a decision requires leaving Inbox.

Choose the reviewer

An explicit Task reviewer takes precedence. Otherwise reviewer defaults resolve through the assigned Agent, Project, Goal, and Workspace. Human-review levels can fall back to the Human who created the Task. Assignment identifies who will judge the result. It does not start review by itself.

An explicitly assigned active reviewer takes precedence and receives the completion at every review level. When reviewer ownership comes from defaults, Routine Agent work has no separate completion gate, Standard and Elevated work use the stored reviewer, and Critical work routes to a Human lead or the Human creator. See Task specs for planning and the risk assessment that establishes the review level.

Review the delivered result

Completion review begins when an Agent's completion reaches a gated review level, or when a person or Agent moves the Task to In review.

When an Agent submits to a Human reviewer, it first checks the work in a fresh review session. An approval from that first pass sends the result and rationale to the Human's Inbox. A revision returns it to implementation. A rethink returns it to planning. Corrected submissions repeat the check before asking for Human attention. If an assigned final deliverable review Run ends without recording a verdict, Task Machine keeps that exact review pending instead of inventing a request for changes. It retries the same round within a bounded attempt limit, then places the latest safe Run context and a Retry action alongside the normal verdict actions in one Inbox decision. An approved implementer pre-review never becomes the final verdict.

A Human implementer proceeds directly to the assigned reviewer. When the final reviewer is an Agent, that Agent remains the single Agent review rather than adding another preliminary review. If its approved merge cannot complete, the same reviewer may report the unchanged approved head as open with its current CI and mergeability values, including a still-passing and mergeable state, and must not claim a merge.

Decide what happens next

Judge the result against the agreed criteria and evidence, rather than a new preference introduced after delivery.

Explain a correction clearly enough that the next attempt can address it. The verdict remains in Task history, along with the decision to accept the result or send it back.

Keep pull-request review tied to the revision

Code delivery that requires a pull request has revision-bound review and delivery checks. Review the exact change that will be delivered using Pull requests and delivery.

The Inbox decision records your review of the reported revision. It does not merge the pull request. When available, its Merge risk section adds category-level evidence for that same revision, not a verdict or a substitute for required checks. An agent reviewer decides only where the Project and the agent's autonomy allow it, and otherwise the decision comes to a person. See Pull requests and delivery.

A Task that uses a repository only as working context still follows ordinary completion review when pull-request delivery is not required.

Use direct completion deliberately

A person can move a Task straight to Done. That explicit choice bypasses completion review and the Agent-only check for unresolved questions or approvals.

It does not answer an open question or decide a pending approval. Those items remain in Inbox until someone handles them. Use direct completion only when you intend to take responsibility for that state change.