adversarial-review

What this skill does

# Adversarial Review

Two subagents review the same work in parallel, competing under an incentive that rewards in-scope defects with working repros and penalizes nit-padding and feature-proposal drift. The skill enforces scope discipline up front and triages findings against scope before presenting them.

**The failure mode this skill prevents**: without scope, reviewers find "everything" — theoretical contract gaps, "what if a future caller does X" cases, POD nits — and fixes accumulate surface that the next round attacks. Findings count stays high while real signal converges to zero.

## When to Use

- The user asks for an "adversarial review", "review this adversarially", or wants two reviewers competing.
- You have a concrete patch, PR, plan, or change to review (not an open-ended question).
- You can already name the invariants the patch claims and its threat model (the precondition Step 1 enforces).

If you can't supply the preamble, this is the wrong skill. Use `superpowers:requesting-code-review` or `/request-review` instead — those don't require scope to work.

## Required Inputs

The caller MUST provide all of the following. If any is missing, abort using the Step 1 message (which Step 2 also reuses for the round-number case) — do not improvise defaults, do not dispatch with placeholders.

1. **Scope preamble** (Step 1): invariants, threat model, out-of-scope list.
2. **Round number** (Step 2): positive integer counting this invocation.
3. **Work under review**: a patch ref, diff, or file paths.

## Step 1: Scope preamble (hard gate)

Before dispatching, the caller MUST supply:

1. **Invariants** (1-3, crisp): what does the patch claim to make true?
2. **Threat model**: who is the attacker, what's their leverage, what's the impact target?
3. **Out-of-scope list**: which kinds of findings are not in scope? (e.g. "feature proposals", "theoretical contract gaps", "documentation wording")

If the caller can't supply these, **abort** with this exact message:

> adversarial-review requires scope to work. Without invariants and a threat model, reviewers will pad with nits and propose features instead of finding defects. Please supply: (1) invariants the patch claims, (2) threat model, (3) explicit out-of-scope list. Then re-invoke.

Do NOT dispatch with improvised defaults. Do NOT proceed.

## Step 2: Round-number gate

The caller MUST state which round this is — a positive integer (1, 2, 3, ...) where the number counts *the current invocation including this one*. So "round 1" means first invocation on this patch; "round 3" means this is the third.

If the caller can't supply a round number, or supplies something other than a positive integer, abort with the same posture as Step 1 (round number is part of the required input).

If round is 1 or 2: proceed silently to Step 3.

If round >= 3: pause and surface this to the user verbatim (substitute N with the caller-supplied round number, which includes the current invocation):

> You're about to run adversarial-review for the Nth time on this patch. If findings haven't converged, more rounds usually won't help — every fix creates new surface for the next round to attack. Consider **simplifying the patch** (shrink to one or two invariants) instead of adding another round. Continue anyway? [yes / step back]

Only dispatch if the user confirms "yes" (or equivalent affirmation). If the user picks "step back" or asks to simplify, exit without dispatching.

## Step 3: Assemble reviewer brief (verbatim template)

Paste this brief, verbatim, to each subagent (substituting `{...}` placeholders with the caller-supplied content from Step 1 and the work-under-review reference):

```
You are one of two reviewers competing to find serious issues in this work.

WORK UNDER REVIEW: {patch ref / diff / file paths}

INVARIANTS THIS PATCH CLAIMS:
{invariants from preamble}

THREAT MODEL:
{threat model from preamble}

OUT OF SCOPE — these findings are worth ZERO points:
{out-of-scope list from preamble}
- Findings that propose new behavior, new gates, or new discriminators
- Findings that propose the patch should "also handle X" beyond stated invariants
- Documentation/wording nits

If you're unsure whether a finding is in scope, write it under "Hypotheses
Checked Clean" with your reasoning, not under "Findings".

SCORING:
Five points go to the reviewer who finds the most IN-SCOPE DEFECTS WITH WORKING
REPROS. A finding without a repro is worth zero points. A finding that proposes
new behavior is worth zero points.

Anti-splitting rule: findings that share the same invariant violation count as
ONE finding for scoring, no matter how many input variants you list. Don't
split "URL parser breaks" into separate findings for http://, https://, file://.
Pick the strongest single repro and list the variants under it.

A test-quality finding counts only if you can argue, citing the specific
assertion in the test, why the test would PASS against deliberately broken
(pre-patch) code — otherwise the test is real and your finding is theatre.
You don't need to execute the pre-patch code; reason from the assertion.

REQUIRED OUTPUT SECTIONS (use these exact headings):

## Findings
For each finding:
- Title
- Severity (Critical / Important / Minor)
- Invariant violated: {which stated invariant}
- Repro: {minimal code or input sequence demonstrating the defect; list
  additional variants here, not as separate findings}

## Tests Verified Falsifying
If the patch adds no tests, write: "No tests added by this patch." and skip the per-test bullets.
Otherwise, for each test the patch adds/modifies that you ACCEPT as real:
- Test name
- Argue why it would FAIL against pre-patch code: {cite the assertion and
  the pre-patch behavior the assertion would catch}
For each test you REJECT as theatre:
- Test name
- Argue why it would PASS against deliberately broken code: {cite the
  assertion and the trivially-true condition it actually checks}

## Hypotheses Checked Clean
For each attack lane or concern you investigated and dismissed:
- Lane: {what you considered}
- Verdict: {why it's not exploitable / why it's out of scope}

DO NOT propose new features. DO NOT propose new gates or discriminators. DO NOT
flag wording nits.
```

## Step 4: Dispatch in parallel

Use the Agent tool to launch two `general-purpose` subagents in a single message (so they run in parallel). Both get the identical brief from Step 3.

## Step 5: Aggregate + triage

When both subagents return, for each unique finding (after deduplication across the two reviewers), classify as:

- **in-scope** — violates a stated invariant or breaks legitimate use; has a working repro
- **out-of-scope** — proposes new behavior, gates, or discriminators; or extends surface beyond stated invariants
- **wontfix** — cosmetic, style, doc wording

Present only **in-scope** items as actionable. For each out-of-scope finding, write a one-line rejection that names which scope rule excluded it. This step is mandatory — do not pass raw reviewer output through to the user.

## Step 6: Present to user

Structure the final output as:

```
## Actionable findings (in-scope)
{ranked by severity, with repros}

## Hypotheses Checked Clean
{merged from both reviewers — surface what was investigated and came up empty}

## Out-of-scope findings (rejected)
{one line each, with the scope rule that excluded them — so the user can override if they disagree}

## Tests flagged as theatre
{if any}
```

## Common Mistakes

| Mistake | Fix |
|---|---|
| Dispatching without preamble | Skill should refuse — re-read Step 1 |
| Improvising the preamble yourself | Ask the caller; aborting is the right move when scope is unknown |
| Accepting findings without repros | Zero-point findings; don't present them |
| Pass raw reviewer output to user | Triage step (Step 5) is mandatory |
| Run round 4+ without simplifying | Diminishing returns — shrink the patch first |
| Treat "the patch should also do X" as a finding | That's a fea