Second-model review
Put a different model on anything you made, a proposal, a plan, a document, or code. It documents what it finds on one dossier; your agent verifies every finding, fixes the real ones, and hands back the next round.
A model reviewing its own work shares its own blind spots. adversarial-review puts a different model on anything you made: a proposal, a plan or spec, a policy draft, a report, a skill, or code. You don't need to be technical to use it, and it needs no GitHub access unless the target is a pull request. Ask in plain words ("get a second model to check this proposal") or run it as /agent-kevin:adversarial-review in Claude Code or $adversarial-review in Codex.
A model reading your work cold finds what the model that wrote it cannot: the assumptions baked into the prose, the plan, or the commit messages. But a second model's edits may not be something you ship yet. adversarial-review splits the work by trust. The reviewer documents: it reads a brief, hunts, and writes findings. The implementer verifies each finding against the work, fixes what is real, and commits where the target is committed code. Both are the same agent launched from the same home on different models or hosts, so the dossier names the two sides by role, never by model.
The target is any of your own work: a plan, spec, skill, or document by path, or, for code, a PR, a branch, several repositories moving together, or the uncommitted working tree of a repository. For a document, the claims to falsify come from the text's own assertions, since every instruction, name, and number in it is acted on literally by whoever reads it next, and fixes land in the file for you to keep or discard. For code, the claims come from the commit messages, and the reviewer also hunts for structure (a reframing that deletes whole branches, a pass-through layer, a hollow test), with no findings a valid result; for a working tree, from the task and the plan it implements.
The dossier is the whole state. One file per target: a Brief the implementer rewrites every round, a Ledger with one row per finding across rounds, and a Findings and Disposition pair per round. The brief is self-contained (the reviewer needs nothing else from the home) and carries only facts about the work: the product stakes so the reviewer weighs risk like a user, the repositories with exact git diff ranges or the files by path, the bug classes that already bit this work, numbered claims to falsify, and an output contract with the finding shape. Every fix the implementer lands becomes a new claim in the next round's brief, because a fix written under review pressure is as suspect as the original work.
you > get a second model to check this proposal
you > /agent-kevin:adversarial-review reports/plans/2026-09-23-1200-billing-spec.md
you > /agent-kevin:adversarial-review verify (after the reviewer replies with the path)For code:
you > /agent-kevin:adversarial-review brief (current branch against the default branch)
you > /agent-kevin:adversarial-review 142 (a PR, checked out locally)
you > /agent-kevin:adversarial-review ~/Developer/app:main..HEAD ~/Developer/engine:main..HEAD
you > /agent-kevin:adversarial-review --working-tree (the uncommitted work in the code path)The handoff is one line you paste into the reviewer's session, launched from the same home so the file is writable:
Read <dossier path> and do what "Brief for the reviewer" says. Write your findings into that same file under the empty heading "## Round 3 — Findings (Reviewer)". Change nothing else in it and nothing in the repositories or the files under review. When you are done, reply with only the path of the file.verify then runs every finding through the same verification rubric the engineer skill's PR review uses, fixes the confirmed ones in the smallest correct change, runs the repo's build and tests, commits one commit per finding group on your branch (never pushes), rejects the wrong ones with a receipt, marks pre-existing ones inherited, writes the disposition, updates the Ledger, re-cuts the brief at the new heads, and hands you the next round's line. On a working tree or a document the fixes land in place with a suggested commit message each, and you commit. A round with nothing confirmed and nothing open closes the loop.
| Flag | Effect |
|---|---|
--reviewers <n> | Several reviewers on the same round in parallel, each with its own lettered section and handoff line; duplicates verify once |
--working-tree | Review the uncommitted work of a repository: tracked changes plus untracked files, fixes left in the tree |
--no-commit | Fixes stay uncommitted; the refreshed brief points at the working tree |
--refresh | Re-cut the brief at the current heads without opening a round |
--doc <path> | Name the dossier instead of matching it by branch or PR |
While a round is out, the target stays where the brief points. The reviewer modifies nothing in the repositories or the files under review; read-only checks such as a build or a test run are welcome and reported as what ran.
What it never does
- Never posts to GitHub or any chat surface. You carry the handoff line between sessions.
- Never pushes. For code it commits on your own branch only, and only when you asked it to verify; a document is edited in place and never committed.
- Never puts private material in a brief: nothing from the agent home's memory or notes, no secrets, no customer identifiers.