Claude Code Learning Hub
中文 Mingyu's Library

Hub / Tips / A · Reliability & quality

Adversarial review

The Claude that wrote the code will go easy on the code it just wrote — have a “stranger” who knows nothing about the implementation critique the diff alone, and the problems can’t hide.

Subagents are born for the “stranger” role: each subagent starts from a fresh, isolated context, can’t see your conversation history, and so knows nothing of the reasoning that went into the implementation — it can only judge the code as code. The longer Claude works unattended, the more this independent check matters.

One-line answer

Answer Before counting a task as “done,” run one adversarial review: either run the built-in /code-review (audits the current diff for bugs in a brand-new subagent), or write your own prompt that hands a subagent your plan and has it report gaps against the diff. OfficialThe official rationale: in its fresh context the reviewer sees only the diff and the criteria you supply — not the reasoning that produced the code — so it can judge the result strictly on the merits.

Steps

  1. For correctness, use /code-review. Run it right in your working session. OfficialBy default it reviews “commits ahead of upstream on the current branch + uncommitted changes”; you can also point it at a target: file paths, a PR number, a branch name, or a ref range like main...my-feature. The review runs as a background subagent with its own context window and doesn’t crowd your conversation; results return to the session when it finishes. Add --fix to apply the findings directly to the working tree, or --comment to post them as inline PR comments.
  2. Tune the confidence. OfficialPass /code-review an effort level: low/medium reports only the most confident findings with few false positives; high through max casts a wider net and may include uncertain findings. Omit it and it uses the session’s current level.
  3. For “does it match the plan,” write your own prompt. Official/code-review only hunts bugs; to verify against a SPEC/plan, the official formula has three ingredients: name the work under review, name the plan to compare against, and define what counts as a finding. Because the reviewer is a subagent, the gaps land straight back in the implementation session — Claude can fix and re-review on the spot, with no copying between windows on your part.
  4. Stronger isolation: a second session. OfficialThe official Writer/Reviewer pattern: session A implements, session B (completely fresh context) reviews, and you paste B’s feedback back into A to fix. Same reasoning — “a fresh context won’t favor freshly written code.” Our takeThe subagent version wins on closing the loop automatically; the two-session version wins on you personally controlling what the reviewer gets to see. Important changes deserve the latter.
  5. Don’t let the reviewer set the agenda. OfficialThe docs warn explicitly: a reviewer told to find problems will almost always report something, even when the work is fine; chasing every finding drifts into over-engineering (extra abstraction layers, defensive code, tests for cases that can’t happen). Constrain the prompt to “only report gaps that affect correctness or explicit requirements,” and treat everything else as optional suggestions.
  6. Mind how --fix interacts with rollback. OfficialEdits from a background review’s --fix happen outside your session’s checkpoints — /rewind can’t undo them; roll back with git. Details in how to roll back a bad change. Also: on the GitHub side there is a hosted Code Review (research preview, Team/Enterprise plans), triggered by commenting @claude review on a PR; multiple agents review the whole PR and post inline comments by severity — a separate thing from the local /code-review.

Copy-paste prompt

Plan-checking adversarial review (an English rendering of the official formula — swap in your own targets):

Use a subagent to run an adversarial review of the current diff against @SPEC.md:
do not relay any of the implementation process to it — it should see only the diff and the criteria below. Check:
1. Is every requirement in SPEC.md actually implemented?
2. Does every listed edge case have a corresponding test?
3. Was anything changed outside the scope of the task?
Report only gaps that affect correctness or explicit requirements — no style preferences.
When the results come back, sort the findings into "must fix / optional" and show me the list before fixing anything.

For pure bug-hunting, just run:

/code-review

Sources & last verified

  • OfficialBest practices — Add an adversarial review step / Run multiple Claude sessions — the fresh-context rationale, the three-ingredient review prompt, the over-engineering warning, the Writer/Reviewer pattern; fetched 2026-08-05.
  • OfficialCode Review — /code-review targets and the --fix/--comment flags, effort levels, background-subagent execution, the hosted GitHub version; fetched 2026-08-05.
  • OfficialCreate custom subagents — fresh isolated context, no view of conversation history, the code-reviewer example; fetched 2026-08-05.
  • Last verified: 2026-08-05 · volatility: high (tied to /code-review flags and subagent behavior; re-checked periodically).