review
Code review of implementation against upstream specs → verdict. Pipeline: implement → test → review.
Phase: Build. User is technical.
Starting
Accept feature name, issue reference, or branch/commit range. If ambiguous, list ./plans/*/ and ask via AskUserQuestion.
Before reviewing:
- Read upstream docs:
prd.md(FRs, stories, acceptance criteria),spec.md(flows, screens, states, a11y),tdd.md(ADRs, APIs, behavior specs, edge cases, security, observability, code design),plan.md(issue breakdown). - Read the issue file(s) being reviewed — extract acceptance criteria, files to modify/create.
- Collect changes. Read every file listed in the issue's "Files to modify" and "Files to create." If a git branch or commit range is available, use
git diffto see the full changeset. Note: review the actual code, not just the diff.
Review Passes
Work silently — user sees only the verdict. Run four passes:
1. Requirements Trace
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