Attack the plan for $ARGUMENTS before anything is built on it. If $ARGUMENTS is empty, ask for the plan file's path.

The plan is the one artefact every later step inherits. A wrong assumption in it is copied faithfully by whoever writes the code, and comes back as a clean diff doing the wrong thing — green gates, passing tests, no behaviour change. No review downstream catches that, because every downstream review checks the work against the plan rather than the plan against the repo.

What this run must produce

1. A findings file at the path the plan names, or PLAN-REVIEW.md beside the plan, written by you from the attacker's report.
2. Every finding closed: fixed in the plan, rejected with the reason written into the plan itself, or escalated to the owner and answered.
3. A one-line verdict in the final message: how many findings, how many fixed, how many rejected and why, how many escalated.

No implementation starts while a finding is open. Silence is not a rejection.

Step 0 — Is this plan worth attacking?

Skip a mechanical change inside one package that creates no file, adds no dependency and touches no schema: a rename, a config flag on a value the plan has already traced to its reader, a test for behaviour that already exists. There the plan is short enough that a wrong assumption shows up as a failing gate rather than as a clean diff.

Never skip for:

• a defect class rather than a list of sites — "fix every place that does X" — however mechanical each fix looks. What a plan gets wrong there is the boundary of the class, and no gate can fail on a site nobody found. A batch that passed every skip test above (one package, no new files, no schema) went to this stage anyway and came back with two more instances, one of them a GDPR erasure path that could never complete.
• anything touching auth, tokens, sessions, a D1 schema, a Worker binding, or a build config another package inherits
• more than one package, a new dependency, or a new file

When in doubt it runs. The stage costs one round trip; the failure it catches costs the branch.

Step 1 — Make the plan attackable

The plan must be a file on disk, because the attacker gets a fresh context and reads it cold. new-feat writes NEW-FEAT.md; orchestrate uses the phase's plan under docs/superpowers/plans/. Either is fine — pass the path.

Before dispatching, check the plan carries the three things this stage most often finds missing. Each is cheap to add now and expensive to discover later:

• Every config value the plan says to set names the file and line that reads it. No citation means the instruction is a guess. This is the single most productive check in the stage: a plan once said to set vite: { build: { minify: true } }, the framework hard-set minify: false after reading it, and the whole task shipped as a no-op that passed every gate. A value read in more than one place is a second finding, not the same one — the same plan's sourcemap: true was also read by the client build, which would have published the app's source maps to a public directory.
• A build-config change names the directories the build writes, and which of them are served publicly. "The build passes" is not the same as "the output is what I expected".
• The issue's premise, and the wiki claims the design rests on, verified. An issue written weeks ago states what was true then. Check the sentence the work rests on before the plan inherits it: an issue reading "only one of six apps has a guard" implied five apps of the same shape, and five of the six turned out to be a different shape entirely. A wiki page the plan quotes as fact is the same kind of inherited claim, and a recently reviewed page can still be wrong about the one behaviour the design needs.

Step 2 — Dispatch the attacker

The attacker agent (.claude/agents/attacker.md). A fresh context reading cold is the point: it does not inherit your reasoning and cannot agree with you out of habit. Never continue your own session for this, and never dispatch the agent that wrote the plan.

The prompt, adapted to the plan's path:

Read <plan path>. Attack it. You are not here to improve the wording.

Report:

• wrong assumptions about how this repository works
• dependencies missing from the task list, or steps in an order that cannot work
• any step whose stated definition of done does not prove the goal — especially a command that would not actually run the thing it claims to test
• paths, symbols, scripts or package names the plan names that do not exist
• any config value the plan sets whose reader the plan does not cite, and any it cites that is read somewhere else as well
• anything the plan calls easy that is an auth, schema, binding, migration or build-config problem in disguise
• the premise the plan inherited from its issue, or any wiki or documentation claim it relies on, that the code contradicts
• a test case the change deletes that the plan's table of deleted tests does not list, or whose named replacement does not cover the same behaviour
• for every decision the plan makes from data it reads at run time (an API response, a record, a file another process writes), ask who else can write that data, what the plan does when it is false, and what it costs when the item it wants is missing (a walk to a cap, a rate limit)
• every cost the plan concedes (an extra round trip, statement, request or re-render that the plan states and accepts): can the design avoid it, and what does keeping it cost?

Cite a file and line for every claim. Do not edit any file, do not run a build, and do not write code. Return the findings as your final report; the caller saves them to <findings path>.

Open the prompt with TASK-BRANCH: <branch> on its own line, before anything else — the collector reads it back out to attribute the attacker's spend to this branch's card (tools/pr-metrics/index.ts, resolveDispatchBranch); a dispatch that omits it banks that spend against whatever branch the dispatching session happened to be on, where nothing will look for it. Then give it the worktree path and the branch, tell it the repository conventions live in AGENTS.md and the wiki, and tell it explicitly not to build — a reviewer that builds in a worktree another process is building in produces measurements that are not real.

Step 3 — Close every finding

The attacker is read-only and writes no file, so never wait on one: its findings arrive as its final report. Write that report to the findings path, replacing any file an earlier run left there. Then read the findings yourself and act on each one. Three outcomes and no fourth:

• Fix the plan. The usual case.
• Reject it, in writing, in the plan — only when you can name the fact it got wrong. One line: the claim, and the file, line or output that shows it false. A rejection you did not write down is indistinguishable from a finding you missed, three steps later when it turns out to matter.
• Escalate it when its facts stand and what is left is the owner's choice: label the issue needs:decision and write the body so they can decide from the issue alone (the write-issue skill, §A needs:decision proposal). Under orchestrate, return NEEDS INPUT: <question> + options + recommendation to the coordinator instead. Close the other findings and finish the plan meanwhile; no code starts until the answer comes back.

A finding whose facts stand is escalated, never rejected. Disagreeing with its trade-off is not a rejection: the owner overrules a rejected trade-off after the branch is built, and the redesign costs far more than the question would have. The same holds for an owner decision. When a finding conflicts with one, or names a case it does not mention, escalate with two options; never reject it by citing the decision. How far a decision reaches is the owner's to say.

Reject with evidence, not with confidence. A rejected finding on this repo turned out to be a reviewer measuring a build directory two processes had written into at once; the tell was a file count that disagreed with what the app emits. Check the claim's numbers against the artefact before you either accept or dismiss it.

An untested guarantee is closed only by a test that fails without it. A finding that the change leaves a guarantee untested is fixed by a planned test that goes red when the guarantee is taken out of the code as it will ship. A mutation run that needs a made-up change first, such as adding a class before removing another, shows only that the test can see the property somewhere. It does not show that anything holds the guarantee.

A finding that a planned step undoes a security control is fixed or escalated, never documented. A step that puts back an old secret or key, widens a permission or skips an approval stays open when the plan only adds a sentence to a runbook. Fix the design, or escalate with the options. Rate such a finding by its consequence, not by how unlikely it looks.

A fix that exempts a class from a bound reopens that bound. Before the finding counts as closed, the plan states the new worst case: the most rows, statements or CPU the class can now use in one run. Check that number against the limits it touches, not against the old cap.

Step 4 — Re-run, or don't

Re-run this stage when the plan changes shape — a new step, a re-cut dependency, a different approach. Not for wording, and not for closing the findings it just produced. A fix that adds an exemption to a bound is a change of shape, so it gets a re-run even though it closes a finding.

Finish

Report the count, what was fixed, what was rejected and the fact each rejection names, and, as a list of its own, what was escalated and where each question waits. The plan is clear to build once every escalation has its answer. Then continue with the skill that called this one.

Two things worth carrying into the run that follows, both of which this stage tends to surface:

• A guard, check or budget the plan adds is not verified until it has been seen to fail. Break the input, watch the non-zero exit. A check that only ever passes is indistinguishable from one that cannot fail.
• Count where findings came from — the plan, the brief, or the implementation. It is the only signal that says which stage to spend more on, and it is usually not flattering to the planner.