adversarial-review

A Claude Code plugin that runs an adversarial, multi-agent review of your uncommitted diff before you commit it.

Most AI review tools have the same failure mode: they hand you a wall of plausible-sounding findings, you check the first three, two are wrong, and you stop reading. This one adds a step — every candidate finding is handed to a skeptic agent whose job is to disprove it. Only findings the skeptic fails to refute reach you, scored by severity × confidence.

It is read-only. It never edits, stages, or commits, and never bypasses a git hook. Fixing what it finds is a separate, opt-in step.

Install

/plugin marketplace add mcarlssen/claude-adversarial-review
/plugin install adversarial-review

Then, in any repo:

/adversarial-review

or just ask Claude to "adversarially review this diff before I commit".

What it does

1. Establishes scope. Staged + unstaged changes, or — if the tree is clean — this branch against its detected base. Handles the merged-PR case by pinning the true merge-base, so a later hot-fix in the working tree can't mask the bug the PR introduced.
2. Fans out parallel reviewers, each with one lens:
   • Semantic correctness — logic, state, races, queries, plus specific traps that survive ordinary review: shared-projection blast radius, identifier round-tripping, feature-flag removal as a live behavior change, string-literal mangling in raw SQL/regex, silent parity gaps when a new code path mirrors an old one, hard-coded labels that only look like they match.
   • Security — OWASP top-10, with injection findings judged against the target grammar's full escape set rather than "we already do it this way".
   • Language convention — idiom and safety issues in whatever languages the diff touches, not style nits the linter already owns.
   • Project convention and precedent — reads your CLAUDE.md, CONTRIBUTING.md, and linter configs, and compares the diff against existing in-repo patterns. Reuse is the default, but a broken precedent gets flagged rather than propagated.
   • Blast radius / production impact — downstream consumers, migration hazards, query plans, backward compatibility for in-flight jobs and cached payloads, plus what to watch and how to roll back. Actively hunts cross-boundary callers that a symbol grep misses (URL path strings, reflective dispatch, job names in config).
   • Over-engineering — the diff's best outcome is getting shorter.
3. Refutes everything. Each finding gets a skeptic; borderline high-severity findings get three, and survive only on a 2-of-3 vote. Crucially, the all-clears get refuted too — a "no callers found" or "handled by the framework" must survive a skeptic searching by a different modality than the one that produced it. Missed bugs are at least as expensive as false positives.
4. Scores and thresholds. risk = severity × post-refutation confidence, bucketed BLOCK / CONSIDER / NOTE, with explicit handling for defects that are real but not yet reachable (latent), real but dependent on an operational fact you have to go check (env/data-gated), and whole PRs of not-yet-wired infrastructure (scored at would-be-reachable weight so design defects don't get buried).

Configuring it for your project

Nothing is required. The skill discovers project rules on its own — the nearest CLAUDE.md, plus CONTRIBUTING.md, AGENTS.md, a docs/ style guide, and linter/formatter configs. If your project states no rules, the convention lens falls back to in-repo precedent.

Two things are worth tuning if you fork it:

• Severity calibration in the security lens (SKILL.md §2). It weights authz gaps and PII leakage high where the code touches financial, health, or credential data. Adjust to your risk profile.
• The BLOCK threshold (risk ≥ 3.5, SKILL.md §4). Lower it if you want a louder reviewer.

Cost

It spawns a lot of subagents — six reviewers plus a skeptic per finding, and up to three on borderline ones. That's the tradeoff for the signal-to-noise ratio. The skill scales reviewer count down for small diffs, but a large, security-sensitive diff is genuinely expensive. Use it before you commit something that matters, not on every save.

Enforcement

Manual only by design — it does not auto-run or gate commits. If you want it to run before every commit, add the guidance to your project's CLAUDE.md or wire a PreToolUse hook yourself.

Attribution

The over-engineering/complexity lens (SKILL.md §2a) is adapted from the MIT-licensed ponytail-review skill by DietrichGebert. Full license and copyright notice: skills/adversarial-review/ATTRIBUTION.md.

License

MIT — see LICENSE.