Adversarial Review

---
name: adversarial-review
description: Runs a hostile review of a spec, plan, or code in a fresh subagent, then fixes what holds. Use when a spec, a plan, or implemented code needs review before the next step; also when asked to review code, hunt for bugs, audit a diff or branch, stress-test a PR before merging, or "tear this apart"; or to resume a paused review.
argument-hint: "[spec, plan, or code]"
---

# Adversarial Review

A reviewer that has not seen this conversation judges the work itself, not the reasoning that produced it. A reviewer will always find something, so a review ends when nothing blocking is open, not when the findings run out.

Ask your partner one question at a time, in plain text; do not use the AskUserQuestion tool, because some clients show only the tool's question and drop the text around it. Put what your partner needs to answer in the same message: the problem and why it matters, then the options, recommended first, each with a short bold label in words (never numbers or letters) and a one-line reason. End with a line naming those labels in the same order, such as `Reply with **new PR**, **straight to main**, or **drop it**.`, and make the question the last thing in the message, after any tool use. Your partner may answer with an option, their own alternative, a question or an aside. Keep messages short: lead with the decision, then only the detail needed to answer it. Before a stretch of work that takes more than a moment, such as dispatching a reviewer, writing a spec or plan, or fixing findings, say in one line what you are about to do; after your partner answers, say what comes next before starting it.

When you find something worth doing later that this work does not include, add it as an item to `.dietpowers/trackers/open-items.md`, following `## Open items` in `${CLAUDE_PLUGIN_ROOT}/shared/trackers.md`, and say so in one line.

Commits follow two rules. Fixes in a code review follow the code-step rule: commit on the feature branch as you go; if you are on `main`, `master` or the plan's `Base:` branch, first ask once: "I'll create branch `<name>` for this work. Reply with **yes** or **no**.", and do no code work until a branch is agreed. Fixes in a spec or plan review follow the document rule: check the plan's `Commits:` line or your partner's earlier answer, and if neither settles it, ask once: "I'll work on branch `<name>`. May I commit the spec and plan to it as we go? Nothing is pushed or merged without asking. Reply with **yes** or **no**." Whatever the answer, move the work to that branch; never commit to `main` or `master`. If your partner declines, leave spec and plan edits on disk; the `dietpowers:finish-branch` skill proposes those commits at the end.

Record the review in a tracker, following `## Working directory` and `## Tracker format` in `${CLAUDE_PLUGIN_ROOT}/shared/trackers.md`; replies to your questions follow its `## Replies`.

0. If your partner asked to resume, follow `## Resuming` in `${CLAUDE_PLUGIN_ROOT}/shared/trackers.md`, then carry on from the step it leads to.
1. Pick the prompt file for the target from this skill's directory, `${CLAUDE_SKILL_DIR}`: `spec-reviewer.md` for a spec (needs `SPEC_FILE_PATH`), `plan-reviewer.md` for a plan (`PLAN_FILE_PATH`, `SPEC_FILE_PATH`), `code-reviewer.md` for code (`SPEC_AND_PLAN_PATHS` or a one-paragraph `REQUIREMENTS`, and `BASE_SHA=$(git merge-base HEAD <base>)`, with `<base>` from the plan's `Base:` line, or ask). Do not read the prompt file yourself. The reviewer grades each finding.
2. Save all work to disk, and commit it: code always, a spec or plan if commits are approved. The reviewer reads the files on disk and git history, never this conversation.
3. Dispatch a `general-purpose` subagent whose whole prompt is: "Read `${CLAUDE_SKILL_DIR}/<prompt file>` and follow it," then the placeholder values. Run it on the same model as this session, and wait for its report before doing anything else. Send nothing else: never your session history, never a pasted diff.
4. Create the tracker with `Second pass: pending`, and write every finding into it at once as an unchecked `open` item, so none is lost if the session ends. Then check each finding against the files and record the evidence under Verified.
5. Decide which findings go to your partner. First read `${CLAUDE_PLUGIN_ROOT}/shared/making-recommendations.md` and follow it; if it cannot be read, say so once and carry on.
   - A minor finding that holds and has one reasonable fix: mark it `fix` and tell your partner in one line, the finding and why it holds. Do not wait for a reply.
   - Every blocker and major finding, and any finding you want to reject, downgrade, or fix in more than one reasonable way, or whose fix changes the approved spec (in a spec review, the approved design): ask your partner, one at a time, most severe first. Offer options from fix as proposed, another fix, **add to open items**, **leave here**, won't fix and reject, recommended first, and end with `Reply with <options in bold>, or **pause**.` Record the question under the item's Question before you ask. **add to open items** and **leave here** both set the item to `deferred`; **add to open items** also adds the finding as an open item. Review findings reach open items only through the **add to open items** answer; the open-items sentence above covers other later work you notice during a review.
   - You may raise a grade on your own; lower one only by asking.
6. Fix once no item is `open`. For code, first record `FIX_BASE=$(git rev-parse HEAD)` in the tracker if it has none, so the fix check sees every fix even when this step runs again. Fix the `fix` items, most severe first. For code, start each fix with a test that reproduces the finding and fails, then make it pass, and commit it. A spec or plan under review is edited directly, and committed if commits are approved. When a fix to a plan or code would alter behavior the approved spec describes, invoke the `dietpowers:update-spec` skill before making it. Mark each item `fixed` with what changed and the commit. If a fix cannot be made, set the item back to `open` with the evidence (what you tried, the failing output) and ask your partner about it.
7. Second pass. If nothing was fixed, set `Second pass: not run (nothing fixed)`. Otherwise dispatch one fix check the same way as step 3, reusing the tracker's reviewer values and adding `FINDINGS` (each fixed item's finding and fix) and, for code, `FIX_BASE`. Never send the tracker. When the report arrives, write all its findings as `open` review-2 items and set `Second pass: done (N findings)` in the same write. Check them as in step 4's second sentence, then handle them as in steps 5 and 6, except that a finding that matches an item in this tracker is marked `duplicate of N` and not asked unless it brings new evidence, in which case show the earlier decision with it. If the fix check fails or returns nothing usable, report it and set `Second pass: not run (<reason>)`. Never dispatch another review.
8. Report to your partner, leading with the outcome: what was fixed, deferred, marked won't fix and rejected, each with its reason, and anything still open. Nothing is appended to the spec or plan; the tracker is the record.

Terminal state: the review is done when no blocker or major item is `open` or `fix`. Ask whether to continue, recommending it only when no blocker or major item is `deferred` either, and end the question with `Reply with **continue**, **revise**, or **stop**.`
- After a spec: "Continue with write-plan?" On yes, invoke the `dietpowers:write-plan` skill.
- After a plan: "Continue with execute-plan?" On yes, invoke the `dietpowers:execute-plan` skill.
- After code: "Continue to finishing?" On yes, invoke the `dietpowers:prove-done` skill.

If your partner chooses to revise, make the changes and run this skill again on the revised work, as a new run with a new tracker. If they choose to stop, report what is on disk and what is uncommitted, and stop.

Depth: ${CLAUDE_PLUGIN_ROOT}/shared/trackers.md, ${CLAUDE_PLUGIN_ROOT}/shared/making-recommendations.md