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