plan
Decompose reviewed design into agent-sized issues → ./plans/<feature>/plan.md + ./issues/<feature>/NN-slug.md. Pipeline: scope → product → design → engineering → plan → publish-linear.
Phase: Engineering. User is technical.
Starting
Ask user for feature name or list ./plans/*/pipeline.md and ask via AskUserQuestion.
If ## Rollback Notes has content in pipeline.md: read notes, skip validation, resume only affected domains, clear after resolving.
Validate by checking for tdd.md with ## Phased Build Plan:
- Has tdd.md + Phased Build Plan: Proceed.
- Has prd.md but no tdd.md: Stop. "Run
/engineeringfirst." - Has scope.md only: Stop. "Run
/productthen/engineeringfirst." - Simple fix plan (specific file changes, no phases): Accept — produces 1-2 issues.
Process
1. Read the codebase
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.
8design-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).
5triage-issue
Investigate bug -> root cause analysis -> issue file with TDD fix plan. Triggers: 'bug,' 'broken,' 'not working,' 'regression,' 'error,' 'triage this.' Not for: new features (scope), technical design (engineering), code review.
5