agent-review

Agent Review

The review step of /implement's repo path. Runs on committed work (never unstaged changes), inside the draft PR. Dispatches a review subagent — fed the diff plus review criteria — and returns structured findings for the recipe to act on.

Dependency-free by default: a fresh install gets working review with nothing beyond dossier-mcp. The richer pr-review-toolkit specialist panel is an opt-in override of this skill (see Project overrides), not a built-in — so /implement never requires the toolkit.

Input

• diff — the committed change to review, as a ref range (default origin/main...HEAD) or a PR number.
• criteria (optional) — focus areas; defaults below.
• context (optional) — the plan-file path and the ticket / acceptance criteria, passed to the reviewer so it can check the change against intent.

Default review criteria (the floor)

• Correctness — does the code do what it claims; do its own commands/claims hold up when checked; logic errors, edge cases, off-by-ones.
• AC coverage — does the change actually satisfy the ticket's acceptance criteria.
• Silent failures / error handling — swallowed errors, missing guards, fallback that hides real failures.
• Internal consistency — self-contradiction; drift from the change's own stated contract.
• Convention consistency — does it match sibling code/patterns in the repo.

A project override can replace or extend these. If the AC / plan context isn't provided, the reviewer flags its absence as a gap rather than silently skipping the AC-coverage and intent checks.

Process

1. Resolve the diff — git diff <range> for a ref range, or gh pr diff <number> for a PR number — plus the list of changed files and the context (plan-file path + AC) if available.
2. Dispatch a review subagent restricted to read-only tools (no Edit/Write/NotebookEdit — e.g. a read-only agent type), so the no-side-effects contract is structurally enforced, not just instructed. Instruct it to:
   • read the diff and the changed files in full;
   • check against the criteria and the AC / plan context;
   • be skeptical and concrete — verify claims, don't praise; where a claim is checkable (a command, a path, an invariant), check it rather than trust it;
   • return findings in the structured format below, plus a one-line verdict.
3. Return the findings to the recipe. Do not loop or apply fixes here — the recipe owns the address→re-review loop and the human ready-to-publish gate (a primitive can't host an interactive gate).