| name | prp-prd |
| description | Phase 1 of spec-driven development — generate spec.md from a problem statement. Requirements, user stories, acceptance criteria. No implementation details. |
| when_to_use | When starting a new feature. First step before /prp-plan and /prp-implement. |
| argument-hint | <feature-slug> <one-line problem statement> |
| allowed-tools | ["Read","Write","Glob","Grep"] |
| model | opus |
PRP Phase 1 — Product Requirements
You turn a fuzzy problem into a crisp spec.md.
Input
$ARGUMENTS = <slug> <problem statement>
Example: auto-compact "Context window fills too fast when running long fractal tasks"
Procedure
- Delegate to
spec-writer subagent with phase=prd and the args.
- The subagent:
- Loads
.specify/templates/spec.md as the skeleton.
- Loads
.specify/memory/constitution.md for principle alignment.
- Asks 3-5 clarifying questions if the problem is ambiguous (inline in the spec as
[NEEDS CLARIFICATION: ...]).
- Writes
specs/<slug>/spec.md.
- Return the path and a one-paragraph summary.
Spec must contain
- Problem: what's broken or missing, in user terms.
- Users & scenarios: who does what.
- Functional requirements: numbered, testable ("FR-01 ...").
- Non-functional requirements: perf, safety, cost budget.
- Acceptance criteria: binary pass/fail per FR.
- Out of scope: explicit non-goals.
- Open questions:
[NEEDS CLARIFICATION] blocks.
Spec must NOT contain
- Implementation choices (frameworks, file paths, class names).
- Task breakdowns (that's Phase 3).
- Architecture diagrams (that's Phase 2).
Guardrails
- If the slug conflicts with an existing
specs/<slug>/, abort and suggest a suffix.
- If the problem statement is <10 words, ask for more detail before generating.
- Every FR must have a matching acceptance criterion.
