review-plan

Review the implementation plan. Assume every section is weak until the plan's own evidence proves otherwise. Your job is to find everything that would cause problems during implementation.

$ARGUMENTS

If the argument names a file path, read that file — it is the plan under review. If sibling artifacts exist beside it ({slug}-requirements.md, {slug}-context.md), read those too before reviewing.

Part 0 - Placeholder scan

Before reviewing substance, scan the entire plan for banned placeholder language. Reference the plan quality rules for the full list of banned patterns.

Every placeholder violation is a Critical finding. If you find more than 3 violations, stop the review and reject the plan immediately. It needs to be rewritten, not reviewed.

Part 1 - Verify what's stated

First, check section completeness. The impl-plan skill requires these sections: Discovery level, Requirements and decisions, Problem, Approach, Who uses this and how, Files to change, Data impact, What existing behavior changes, New dependencies, Access control and authorization, Abuse and edge cases, Out of scope, Risks and rollback, Observability & monitoring, Open questions, Wave 0 validation design, Execution manifest, Workflow artifacts, UI contract, Parallel workstreams, Implementation order, Verification. Any missing section (not present, or present without "N/A" justification) is an Important finding.

Exception: if the plan opens with Tier: compact, the required sections are: Discovery level, Requirements and decisions, Problem, Approach, Files to change, What existing behavior changes, Execution manifest, Implementation order, Verification, plus any triggered extras the plan's own file map implies (data, dependency, UI, or access-control changes). A compact tier claimed for a change whose file map spans multiple non-trivial files is itself an Important finding — compactness is for skip/quick_verify discovery levels only.

Then, for each section of the plan, check whether the content is accurate, complete, and consistent with the codebase:

1. Trace the code. Do the files listed actually exist? Do the described behaviors match what the code does today? Are there files or code paths the plan misses?
2. Check the data impact. Will the migration work against the current schema? Are there existing queries, indexes, or constraints that conflict?
3. Test the assumptions. For each item in "Open questions" and "Risks" - are the stated mitigations actually sufficient? Are the severity ratings honest?
4. Verify the scope boundaries. Does "out of scope" actually stay out, or does the approach quietly depend on something listed as out of scope?
5. Stress the edge cases. For each case listed under "Abuse and edge cases" - is the mitigation real or hand-wavy? Are there obvious cases not listed?
6. Verify workstream independence. If the plan has a "Parallel workstreams" section, cross-reference the file map against the workstream assignments. For each file, check which workstream(s) claim it. If any file appears in more than one independent workstream, flag as Critical - parallel worktree agents will produce merge conflicts on that file. Suggest either: (a) moving the shared file into its own sequential step that runs after both workstreams, or (b) merging the conflicting workstreams into one.
7. Map test coverage. For each behaviour change listed in "What existing behavior changes" and each new capability in the implementation steps, check that the "Verification" section names a specific test covering that behaviour. Flag untested behaviour changes as Important - these are gaps that will pass verification (no test = no failure) but leave the feature unproven.
8. Verify requirement and decision coverage. Every REQ-* and D-* in "Requirements and decisions" must appear in the execution_manifest, implementation order, and verification plan. If any ID is missing from one of those places, flag it as Important. If the missing ID affects authorization, data integrity, security, or destructive behavior, flag it as Critical.
9. Validate the execution_manifest. Every manifest task must include id, wave, depends_on, files_modified, requirements, must_haves, verify, and done. Each must_haves item must be observable in code, test output, command output, manual evidence, or changed files. Missing required fields are Important; missing files_modified or requirements is Critical because workers cannot be routed safely.
10. Check the wave graph. Dependencies must point to existing task IDs and cannot point to later-wave tasks. Same-wave tasks must not share files_modified; shared files must move to a later dependent task or the tasks must be merged. Same-wave file overlap is Critical.
11. Check Wave 0 validation design. Each REQ-* must have a test, fixture, command, or explicit first implementation task that makes it testable before feature work proceeds. Missing Wave 0 evidence is Important.
12. Check workflow artifacts for /build plans. If the plan is for /build, it must describe .build/plans/{slug}-state.md, {slug}-context.md, {slug}-requirements.md, {slug}-plan.md, {slug}-review.md, {slug}-implementation-summary.md, {slug}-verify.md, and {slug}-architect-review.md. Missing required artifact responsibilities are Important.
13. Check UI contract when UI files change. If planned files look like UI/frontend files, the UI contract must name the affected screen or component, required states, responsive checks, and verification method. Missing UI state coverage is Important.

Part 2 - Open review

Now step back from the checklist. Read the plan as a whole and react to it.

1. Are we solving the right problem?
2. Is this the simplest approach that could work?
3. What assumptions might be wrong?
4. What's the riskiest part?
5. What would you do differently?

Test-quality audit

When the plan adds or changes tests, look for weak tests: skipped tests, assertion-free tests, snapshot-only tests for behavior changes, tautological mocks that only assert their own configured return value, and tests that would pass if the production code were removed. Weak tests are Important unless they are explicitly limited to non-behavioral rendering snapshots.

Output

Start with your overall assessment in one sentence. Then list specific findings.

Tag each finding by severity:

• Critical - blocks implementation. Must fix before starting.
• Important - should fix before starting. Will cause problems if ignored.
• Minor - note for later. Won't block progress.

Order findings by impact, highest first. Include the placeholder violation count from Part 0.

End with an explicit verdict: "Proceed to implementation" (no critical findings), "Proceed with fixes" (no critical, but important findings to address), or "Do not proceed" (critical findings that block implementation). One line, no ambiguity.

Do not start coding. Just critique the plan.