Adversarial Review
A normal review asks "is this right?" and confirms intent. Adversarial
review asks "how could this be wrong?" and hunts for the fault the first
pass rationalised away. It is a second pass for residual risk on
high-stakes work — not a replacement for the first pass, and not for
low-stakes or reversible changes where it only manufactures busywork.
This is a thin posture, not a new checklist. It layers four moves —
isolation, inverted objective, a triage gate, and a bounded loop — on top of
the domain checklists that already live in code-review, security-audit,
verify-before-plan, and cold-read-gate. It dispatches an isolated
reviewer with the matching lens and then triages what comes back, because
an agent told to find faults will invent them.
When to Use This Skill
| Use this skill when... |
Use something else instead when... |
| Stakes are high and a normal review already passed, but residual risk remains |
First-pass review of a diff/PR → code-quality-plugin:code-review |
| Red-teaming an architecture decision, ADR, or migration plan before commit |
Verifying plan facts (counts, paths, build state) → agent-patterns-plugin:verify-before-plan |
| Stress-testing a design's failure modes and invariants |
Pure security audit → agents-plugin security-audit / /security-review |
Probing whether outward text survives a reader → wrap cold-read-gate |
Legibility of outward text on its own → agent-patterns-plugin:cold-read-gate |
| The change is hard to reverse and a missed fault is expensive |
The change is low-stakes, reversible, or throwaway — skip; it wastes tokens |
The Four Moves
| Move |
What it means |
Borrowed from |
| Isolation |
The reviewer gets the artifact with no author context — bias can't leak in |
cold-read-gate |
| Inverted objective |
Brief says "enumerate failure modes," never "confirm it works" |
this skill |
| Triage gate |
Separate genuine faults from manufactured objections before acting |
cold-read-gate Step 3 |
| Bounded loop |
One revise round; a third means a structural problem the gate can't fix |
cold-read-gate Step 4 |
Model choice is the inverse of cold-read-gate. That skill uses haiku
on purpose — the weak reader is the measurement instrument for legibility.
Adversarial review wants opus: finding subtle faults is a reasoning
task, not a low-context-reader simulation.
Parameters
Parse $ARGUMENTS:
- Target (first positional) — what to attack: a path, a PR ref
(
#123 or URL), a file, or a free-text description of a plan/decision.
If absent, default to the current diff (git diff + staged) and say so.
- Focus directive (optional, free text after the target, e.g.
focus on the failure path, ignore style) — biases the lens. It
steers, never overrides: it must not cancel a live user boundary
stated earlier in the session (the auto-mode.md conversation-boundary
hazard).
Execution
Execute this adversarial review:
Step 1: Precondition gate
Confirm both hold before spending tokens:
- Stakes are high — the change is hard to reverse, or a missed fault
is expensive. If not, stop and recommend a normal review instead.
- A first pass exists — a normal review/lint/test pass already ran.
If not, run that first (
code-review) — adversarial review is a
second pass, and leading with it skips cheap, high-yield findings.
If either fails, say so and redirect rather than proceeding.
Step 2: Name the target and pick the lens
State in one line what is under review, then select the lens. The lens
supplies the domain attack vocabulary — delegate to the owning skill's
checklist rather than restating it:
| Target type |
Lens / attack vocabulary |
Delegate the checklist to |
| Code, diff, PR |
Logic errors, edge cases, race conditions, error-swallowing |
code-quality-plugin:code-review, code-review-checklist |
| Security surface |
Injection, authz gaps, secret exposure, trust boundaries |
agents-plugin security-audit, /security-review |
| Architecture / ADR |
Coupling, failure domains, blast radius, reversibility |
blueprint adr-validate, adr-relationships |
| Plan / wave premise |
Premise truth, stale facts, name≠behaviour |
agent-patterns-plugin:verify-before-plan |
| Outward text / docs |
Legibility under zero context |
agent-patterns-plugin:cold-read-gate |
| Research claims |
Unverified or single-sourced claims |
.claude/skills/deep-research |
Step 3: Dispatch the isolated reviewer
One Agent per lens. model: opus is the floor — see .claude/rules/agent-development.md
§ "Model Selection for Agents" — and model: fable is sanctioned here too:
adversarial review is exactly the hardest delegated-reasoning work that guard
accepts, so the reviewer must not be weaker than the author it is attacking.
Dispatch lenses in parallel only when there are several and the session is not
on a 1M-context model (every Fable 5.1 session, or Opus with the [1m]
suffix) — the parallel-subagent rate-limit caveat in skill-fork-context.md.
Template:
subagent_type: general-purpose
model: opus # floor; fable also sanctioned — see agent-development.md
prompt: |
You are an adversarial reviewer. Your ONLY objective is to find ways this
is WRONG, fragile, or unsafe — do not confirm that it works, do not
praise it. Assume a fault exists and locate it.
Read ONLY the target (no scope beyond it):
<target path / diff / pasted plan>
Attack along this lens: <lens from Step 2, with its checklist>.
<focus directive, if any>
Produce:
1. FAULTS — each as: SEVERITY=critical|high|medium EVIDENCE=<file:line or
quoted claim> FAILURE=<the concrete way it breaks>.
2. ASSUMPTIONS-ATTACKED — load-bearing assumptions you tried to falsify,
and whether each held.
3. VERDICT: exactly one of `sound` | `flawed`.
Cite evidence for every fault. Your final message is the deliverable.
Step 4: Triage — genuine fault vs manufactured objection
The reviewer was told to find faults, so some "faults" are noise. Triage
before acting (this is the load-bearing step — skipping it is how
adversarial review sends you down the wrong path):
| Genuine fault — act on it |
Manufactured objection — drop it |
| A concrete input/state that breaks the code, with evidence |
A defense against an input the contract makes impossible |
| A failure mode with real blast radius |
A hypothetical with no realistic trigger |
| A violated invariant or unhandled error path |
Style/preference dressed up as a fault |
| A premise that is actually false |
Re-litigating a trade-off already decided with rationale |
| A missing edge case the spec implies |
Scope the change didn't touch and isn't responsible for |
Step 5: Report and bound the loop
Emit a prioritised report: target, verdict, surviving genuine faults
(severity-ordered, with evidence and a suggested fix), and explicitly note
the objections you dropped in triage and why. Apply or hand off the genuine
fixes. Re-dispatch a fresh reviewer only if the verdict was flawed;
do not loop more than twice — a third round means a structural problem the
review can't resolve.
Anti-patterns
| Mistake |
Correct approach |
| Running it as a first pass |
It's a second pass — a normal review runs first (Step 1) |
| Using it on low-stakes / reversible work |
Skip it; the precondition gate exists to say no |
| Acting on every objection the reviewer raises |
Triage first (Step 4); the inverted objective guarantees noise |
| Using a weak model "to be tougher" |
Opus — subtle faults are a reasoning task (inverse of cold-read-gate) |
| Restating each lens's checklist inline |
Delegate to the owning skill; this is a posture, not a checklist |
| Looping until the reviewer goes silent |
One revise round; persistent faults = structural problem |
Related
cold-read-gate — the isolation + triage +
bounded-loop pattern this skill generalises (legibility lens; uses haiku)verify-before-plan — adversarial review
of premises; the plan/wave lens delegates hereexecution-grounded-review — the
sibling verifier for running behaviour against acceptance criteria (this
skill attacks a design; that one grounds each criterion in execution evidence)code-quality-plugin:code-review — the first-pass review this layers on top ofagents-plugin security-audit / /security-review — the security lens.claude/rules/terminology.md — defines Adversarial review and Red-team.claude/rules/skill-fork-context.md — the [1m] parallel-dispatch caveat.claude/rules/loop-integrity.md — looping skills delegate their stop-condition judgement to an isolated reviewer like this one (Pillar 1)
1---
2name: adversarial-review
3description: Adversarial second-pass review that tries to break code, designs, plans, or ADRs. Use when stakes are high and a normal review already ran.
4args: "[target] [focus directive]"
5argument-hint: "path|PR|file|plan description; optional 'focus on X'"
6allowed-tools: Agent, Read, Glob, Grep, Bash(git diff *), Bash(git log *), Bash(gh pr view *), TodoWrite
7model: opus
8created: 2026-06-21
9modified: 2026-09-02
10compatibility: claude-code
11reviewed: 2026-09-02
12---
13
14# Adversarial Review
15
16A normal review asks *"is this right?"* and confirms intent. Adversarial
17review asks *"how could this be wrong?"* and hunts for the fault the first
18pass rationalised away. It is a **second pass for residual risk on
19high-stakes work** — not a replacement for the first pass, and not for
20low-stakes or reversible changes where it only manufactures busywork.
21
22This is a **thin posture**, not a new checklist. It layers four moves —
23isolation, inverted objective, a triage gate, and a bounded loop — on top of
24the domain checklists that already live in `code-review`, `security-audit`,
25`verify-before-plan`, and `cold-read-gate`. It dispatches an isolated
26reviewer with the matching lens and then **triages** what comes back, because
27an agent told to find faults will invent them.
28
29## When to Use This Skill
30
31| Use this skill when... | Use something else instead when... |
32|---|---|
33| Stakes are high **and** a normal review already passed, but residual risk remains | First-pass review of a diff/PR → `code-quality-plugin:code-review` |
34| Red-teaming an architecture decision, ADR, or migration plan before commit | Verifying plan *facts* (counts, paths, build state) → `agent-patterns-plugin:verify-before-plan` |
35| Stress-testing a design's failure modes and invariants | Pure security audit → `agents-plugin` security-audit / `/security-review` |
36| Probing whether outward text survives a reader → wrap `cold-read-gate` | Legibility of outward text on its own → `agent-patterns-plugin:cold-read-gate` |
37| The change is hard to reverse and a missed fault is expensive | The change is low-stakes, reversible, or throwaway — skip; it wastes tokens |
38
39## The Four Moves
40
41| Move | What it means | Borrowed from |
42|---|---|---|
43| **Isolation** | The reviewer gets the artifact with no author context — bias can't leak in | `cold-read-gate` |
44| **Inverted objective** | Brief says "enumerate failure modes," never "confirm it works" | this skill |
45| **Triage gate** | Separate genuine faults from manufactured objections **before** acting | `cold-read-gate` Step 3 |
46| **Bounded loop** | One revise round; a third means a structural problem the gate can't fix | `cold-read-gate` Step 4 |
47
48> **Model choice is the inverse of cold-read-gate.** That skill uses *haiku
49> on purpose* — the weak reader is the measurement instrument for legibility.
50> Adversarial review wants **opus**: finding subtle faults is a reasoning
51> task, not a low-context-reader simulation.
52
53## Parameters
54
55Parse `$ARGUMENTS`:
56
57- **Target** (first positional) — what to attack: a path, a PR ref
58 (`#123` or URL), a file, or a free-text description of a plan/decision.
59 If absent, default to the current diff (`git diff` + staged) and say so.
60- **Focus directive** (optional, free text after the target, e.g.
61 `focus on the failure path, ignore style`) — biases the lens. It
62 **steers, never overrides**: it must not cancel a live user boundary
63 stated earlier in the session (the `auto-mode.md` conversation-boundary
64 hazard).
65
66## Execution
67
68Execute this adversarial review:
69
70### Step 1: Precondition gate
71
72Confirm both hold before spending tokens:
73
741. **Stakes are high** — the change is hard to reverse, or a missed fault
75 is expensive. If not, stop and recommend a normal review instead.
762. **A first pass exists** — a normal review/lint/test pass already ran.
77 If not, run that first (`code-review`) — adversarial review is a
78 *second* pass, and leading with it skips cheap, high-yield findings.
79
80If either fails, say so and redirect rather than proceeding.
81
82### Step 2: Name the target and pick the lens
83
84State in one line what is under review, then select the lens. The lens
85supplies the domain attack vocabulary — **delegate to the owning skill's
86checklist rather than restating it**:
87
88| Target type | Lens / attack vocabulary | Delegate the checklist to |
89|---|---|---|
90| Code, diff, PR | Logic errors, edge cases, race conditions, error-swallowing | `code-quality-plugin:code-review`, `code-review-checklist` |
91| Security surface | Injection, authz gaps, secret exposure, trust boundaries | `agents-plugin` security-audit, `/security-review` |
92| Architecture / ADR | Coupling, failure domains, blast radius, reversibility | blueprint `adr-validate`, `adr-relationships` |
93| Plan / wave premise | Premise truth, stale facts, name≠behaviour | `agent-patterns-plugin:verify-before-plan` |
94| Outward text / docs | Legibility under zero context | `agent-patterns-plugin:cold-read-gate` |
95| Research claims | Unverified or single-sourced claims | `.claude/skills/deep-research` |
96
97### Step 3: Dispatch the isolated reviewer
98
99One `Agent` per lens. `model: opus` is the floor — see `.claude/rules/agent-development.md`
100§ "Model Selection for Agents" — and `model: fable` is sanctioned here too:
101adversarial review is exactly the hardest delegated-reasoning work that guard
102accepts, so the reviewer must not be weaker than the author it is attacking.
103Dispatch lenses in parallel only when there are several and the session is not
104on a 1M-context model (every Fable 5.1 session, or Opus with the `[1m]`
105suffix) — the parallel-subagent rate-limit caveat in `skill-fork-context.md`.
106Template:
107
108```
109subagent_type: general-purpose
110model: opus # floor; fable also sanctioned — see agent-development.md
111prompt: |
112 You are an adversarial reviewer. Your ONLY objective is to find ways this
113 is WRONG, fragile, or unsafe — do not confirm that it works, do not
114 praise it. Assume a fault exists and locate it.
115
116 Read ONLY the target (no scope beyond it):
117 <target path / diff / pasted plan>
118
119 Attack along this lens: <lens from Step 2, with its checklist>.
120 <focus directive, if any>
121
122 Produce:
123 1. FAULTS — each as: SEVERITY=critical|high|medium EVIDENCE=<file:line or
124 quoted claim> FAILURE=<the concrete way it breaks>.
125 2. ASSUMPTIONS-ATTACKED — load-bearing assumptions you tried to falsify,
126 and whether each held.
127 3. VERDICT: exactly one of `sound` | `flawed`.
128 Cite evidence for every fault. Your final message is the deliverable.
129```
130
131### Step 4: Triage — genuine fault vs manufactured objection
132
133The reviewer was told to find faults, so some "faults" are noise. Triage
134**before** acting (this is the load-bearing step — skipping it is how
135adversarial review sends you down the wrong path):
136
137| Genuine fault — act on it | Manufactured objection — drop it |
138|---|---|
139| A concrete input/state that breaks the code, with evidence | A defense against an input the contract makes impossible |
140| A failure mode with real blast radius | A hypothetical with no realistic trigger |
141| A violated invariant or unhandled error path | Style/preference dressed up as a fault |
142| A premise that is actually false | Re-litigating a trade-off already decided with rationale |
143| A missing edge case the spec implies | Scope the change didn't touch and isn't responsible for |
144
145### Step 5: Report and bound the loop
146
147Emit a prioritised report: target, verdict, surviving genuine faults
148(severity-ordered, with evidence and a suggested fix), and explicitly note
149the objections you dropped in triage and why. Apply or hand off the genuine
150fixes. Re-dispatch a fresh reviewer **only if the verdict was `flawed`**;
151do not loop more than twice — a third round means a structural problem the
152review can't resolve.
153
154## Anti-patterns
155
156| Mistake | Correct approach |
157|---|---|
158| Running it as a first pass | It's a second pass — a normal review runs first (Step 1) |
159| Using it on low-stakes / reversible work | Skip it; the precondition gate exists to say no |
160| Acting on every objection the reviewer raises | Triage first (Step 4); the inverted objective guarantees noise |
161| Using a weak model "to be tougher" | Opus — subtle faults are a reasoning task (inverse of cold-read-gate) |
162| Restating each lens's checklist inline | Delegate to the owning skill; this is a posture, not a checklist |
163| Looping until the reviewer goes silent | One revise round; persistent faults = structural problem |
164
165## Related
166
167- [`cold-read-gate`](../cold-read-gate/SKILL.md) — the isolation + triage +
168 bounded-loop pattern this skill generalises (legibility lens; uses haiku)
169- [`verify-before-plan`](../verify-before-plan/SKILL.md) — adversarial review
170 of *premises*; the plan/wave lens delegates here
171- [`execution-grounded-review`](../execution-grounded-review/SKILL.md) — the
172 sibling verifier for *running behaviour* against acceptance criteria (this
173 skill attacks a design; that one grounds each criterion in execution evidence)
174- `code-quality-plugin:code-review` — the first-pass review this layers on top of
175- `agents-plugin` security-audit / `/security-review` — the security lens
176- `.claude/rules/terminology.md` — defines *Adversarial review* and *Red-team*
177- `.claude/rules/skill-fork-context.md` — the `[1m]` parallel-dispatch caveat
178- `.claude/rules/loop-integrity.md` — looping skills delegate their stop-condition judgement to an isolated reviewer like this one (Pillar 1)
laurigates