Verify Plan - a risk-coverage audit of a plan before you build

A plan built perfectly is still wrong if the plan was wrong - the design carries the quality: a build handles the traps its plan names and ships the ones it misses, and catching the miss here on the page is cheaper than any downstream gate (the code, the tests, /code-review). This reviews an EXISTING plan or design (yours, or one superpowers:writing-plans produced) for the defects that are expensive to discover later. It does not write or fix code; it flags gaps in the plan and hands them back.

When to use / not

• Use it the moment a plan exists and before implementation starts - especially for anything with a boundary, state, auth, migration, or concurrency surface.
• Not code review - that is /code-review, after the build.
• Not plan creation - that is superpowers:writing-plans / superpowers:brainstorming. This audits a plan that already exists.

The audit - four passes, in order

Load the plan's target stack skill FIRST, so you check against the right trap list, not a generic one.

1. Risk coverage - the highest-leverage pass. Does the plan NAME the non-obvious failure modes this feature will hit? Do not carry a generic checklist - load the stack's house skill (the same one your project's convention rules auto-attach for its file types; its router names the specialist siblings) and check the plan against ITS trap list: the data-access, lifecycle, concurrency, and boundary traps that stack actually has. A trap the plan does not name is a trap the build inherits - flag each missing one and where in the plan it belongs.
2. Scope match. The plan covers exactly what was asked - nothing missing, nothing speculative added (the ponytail 'ultra' test). A step for a requirement that is not there, or a missing step for one that is, is a finding.
3. Edges + safety. Boundary, empty, and error cases are named, not assumed. Any auth / migration-order / data-loss / concurrency surface is called out WITH its safeguard. Silence on a safety-critical edge is a finding.
4. Soundness. The approach matches the repo's existing architecture (match it, never introduce a second), dependencies are ordered, and it is the smallest plan that meets the requirement.