review-plan
What This Skill Does
Evaluate and pressure-test an existing feature plan for technical soundness, system fit, feasibility, scope control, and implementation readiness. Read the plan and codebase, verify claims against reality, apply adversarial analysis lenses to surface hidden risks and overengineering, deliver a verdict. No new documents are produced.
This is the design review step in the planning pipeline (plan-feature → write-a-prd → review-prd → ubiquitous-language → design-feature → review-plan). This is the last checkpoint before implementation — your job is to find what was missed, underweighted, or left unsaid.
Finding the Plan
Look for the plan in this order:
- If the user names a specific file, read that file.
- Check
./plans/for design files (*-design.md). If there's exactly one, use it. If there are several, ask which one. - If the plan was produced earlier in this conversation (via design-feature), use the conversation context.
If no plan can be found, say so and stop. Do not fabricate a review.
If the plan is obviously a partial draft (missing major sections like the Phased Build Plan), note this and recommend completing the plan before a full review. Do not review a half-finished plan as if it were complete.
Check for upstream documents
More from michaelmerrill/skills
design
Design specification interview → standalone spec.md (flows, screens, states, components, responsive, a11y). Triggers: 'design this,' 'what screens,' 'how should users interact,' post-product. Not for: technical design (engineering), requirements (product). Skip for API-only, CLI, backend, or infra features.
8plan
Decompose technical design into agent-sized implementation issues → numbered markdown files + standalone plan.md. Triggers: 'plan this,' 'break into issues,' 'create tasks,' 'ready to implement,' post-engineering. Not for: designs without file paths/phases (run engineering first).
7design-ux
MUST USE when a user wants to design user flows, interaction patterns, or screen-level UX for a feature that has defined requirements. This is the UX design step in the planning pipeline (write-a-prd → review-prd → glossary → design-ux → design-feature → review-plan). Typical signals — "design the UX," "how should users interact with this," "what should the UI look like," "design the flows," "design-ux," "what screens do we need," or following up after a review-prd or glossary session. Also applies when the user has a PRD and wants to figure out the user experience before technical design. Conducts a structured interview to produce a UX specification — user flows, screen inventory, component mapping, interaction specs, and accessibility requirements. Do NOT use for technical design (use design-feature), writing requirements (use write-a-prd), reviewing plans (use review-plan), scoping/feasibility (use plan-feature), or when the feature has no user-facing UI (API-only, backend, CLI tools).
6plan-feature
Scoping interview for new features -> scope doc with go/no-go. Triggers: user wants to add/build/implement any new capability. First pipeline step. Not for: bugs, PRDs (write-a-prd), design (design-feature), executing existing specs.
6define
Product requirements → living doc Requirements section + quality gate + domain glossary. Stateful: detects existing sections and resumes where needed. Triggers: 'define this,' 'write a PRD,' 'define requirements,' 'spec this out,' post-explore. Not for: scoping (explore), UX (design), technical design (architect).
5explore
Scope and assess new feature ideas → living doc with go/no-go. Elaborates vague ideas into clear concepts. First pipeline step. Triggers: user wants to add/build/implement any new capability. Not for: bugs (triage-issue), requirements (define), design (design/architect).
5