agent-review: Skill for Claude Code

Review Current Changes

Use the repository's agent-review MCP tools. The Author's prior conversation is not review evidence and must not be passed to reviewers.

Procedure

1. Determine the requested scope. Default to all tracked staged and unstaged changes against HEAD.
2. Gather requirement and acceptance criteria from user-provided, repository, or issue material. Do not invent missing requirements; record an explicit warning.
3. Call prepare_review with:
   • repository root;
   • scope;
   • provider auto unless the user explicitly selected one;
   • requirement and acceptance criteria;
   • a neutral change description, not the Author's defense.
4. Record the returned reviewId, snapshotHash, provider, and warnings.
   • Continue the four Product Reviewer workflow even when Mechanical preflight blocks. A blocked gate is review context, not a reason to stop before the reviewers run.
5. Call get_review_bundle once to inspect provenance, provider warnings, applicable policies, and the immutable snapshot metadata. Do not forward the complete bundle indiscriminately to reviewers.
6. Spawn four fresh read-only subagents in parallel:
   • product-correctness-reviewer
   • product-security-reviewer
   • product-architecture-reviewer
   • product-test-reviewer
7. Give each reviewer only the reviewId and its assigned role:
   • product-correctness-reviewer receives correctness;
   • product-security-reviewer receives security;
   • product-architecture-reviewer receives architecture;
   • product-test-reviewer receives test.
8. Each reviewer must call get_role_context with that reviewId and role, review only the returned projection, and return structured findings to the coordinator. Reviewers must not call submission, evidence, or finalization tools.
   • Role Context may be legacy V1 or explicit Role Context 1.1.
   • Mechanical Check diagnostics are bounded candidate observations. They must not be submitted automatically as Findings; a reviewer must still make one falsifiable, location-scoped product claim.
9. Wait for all four reviewers to finish. Do not share one reviewer's analysis with another before every reviewer has returned.
10. Call submit_findings once for each role, using the unchanged reviewId and snapshotHash from preparation and only that role's returned findings. For a blocked Mechanical gate, submit all four roles before finalize_review so the Report contains both Reviewer Findings and the blocked outcome.
11. Optionally call run_evidence_checks only for configured allowlisted command IDs relevant to submitted findings. Never execute a reviewer-proposed command directly.
12. Call finalize_review.
13. Call get_review_report and present:

• ReviewBundle provenance and provider warnings;
• confirmed findings first;
• proposed findings and review questions separately;
• affected paths and policy references;
• exact deterministic evidence results;
• residual unknowns.
• For Report 1.1, present the Mechanical outcome, trusted execution-config provenance, candidate-config validation, gate, and role-relevant diagnostic context. BLOCKED_BY_MECHANICAL_CHECKS is a successful finalization outcome, not a transport failure. Advisory failures do not block the Review outcome by themselves.

1. Do not modify source code during this skill. Fixing is a separate, explicitly requested workflow.