review

Review (Protocol)

Overview

Use this skill when you need a repeatable adversarial code review debate that stays grounded in evidence:

• Attacker produces a small set of provable findings (top 10–12)
• Defender responds to each finding by ID (accept/dispute/context)
• Attacker rebuttal closes the loop (concede/maintain/escalate)
• Moderator/Judge produces the final verdict (confirmed/dismissed/contested + priority)

In a typical PR review:

• Attacker = reviewer
• Defender = author
• Judge/Moderator = final arbiter

Success looks like: findings that a developer can act on immediately (location + evidence + minimal fix direction), with noise pruned.

Inputs / Outputs

Inputs: Diff, PR, or commit range to review; archobs JSON from archobs show all --format json (required for non-tiny changes); review type selection. Outputs: Verdict with CONFIRMED/DISMISSED/CONTESTED findings, fix priorities (P0/P1/P2), systemic risk notes. Consumed by finish for ship-readiness.

Workflow

1. Confirm parameters
   • Review type (default for PRs): general | security | correctness | performance | maintainability | testing | architecture | resilience | api-design | accessibility
   • Review artifact (preferred): PR link / diff / commit range / file list (vs “entire repo”)
   • Scope boundaries: default to changed code + immediate call-chain context unless user requests a full audit
   • Archobs dependency — For tiny changes (typo, copy, single-file rename), skip archobs and proceed directly to Phase 1. For all other scopes: archobs is required — wait for completion before continuing. Before starting the debate phases, run archobs analysis (see archobs) to generate coupling data, risk hotspots, and boundary health metrics. Reuse .archobs/file_metrics.parquet only when it is newer than the most recent commit (git log -1 --format=%ct) and .archobs/run_manifest.json exists with status equal to complete; otherwise regenerate and wait for the report to finish before proceeding. Then run archobs show all --format json to load the results. Do not start Phase 1 (Critique) until archobs output is available. Use the archobs output to ground findings in measured data — especially for systemic risks, hotspot identification, and prioritization.
   • Which "workers" you can call (other models, other agents, humans), or whether you will role-play the workers yourself.
2. Create a temporary run directory (scratch)
   • Create a temporary run directory (outside the repo, e.g. mktemp -d).
   • If you run multiple debates in one session, create one subfolder per debate (e.g. debate-01/, debate-02/).
   • Inside each debate folder, save the raw phase outputs as:
     • 1-critique.md (or .txt)
     • 2-defense.md (or .txt)
     • 3-rebuttal.md (or .txt)
     • 4-verdict.md (or .txt)
   • Do not show raw phase artifacts to the user unless they ask; default to a single human-readable report.
3. Phase 1: Critique (Attacker)
   • Use the base attacker prompt + the type add-on from references/protocol.md.
   • Enforce strict format and cap to ~10–12 findings. If off-format, require a rewrite before continuing.
4. Phase 2: Defense (Defender)
   • Require exactly one response per Finding ID.
   • For disputes, require file+line evidence.

GATE: Defense (Phase 2) must contain a response for every Finding ID from Phase 1. At least one dispute must include file+line evidence — a defense that accepts every finding without evidence is not adversarial and produces no signal.