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