/product-prd — Product Requirements Document
Write structured PRDs that define what to build and why. PRDs are product-focused — they describe the problem, users, and requirements without prescribing technical implementation.
When to Use
- User says "write a PRD", "product requirements", "feature spec"
- After a brainstorm session, to formalize requirements
- When a feature idea needs to be documented before building
Process
Step 1: Gather Context
Check for existing artifacts:
docs/brainstorms/— Use brainstorm output as starting point- User-provided description or
$ARGUMENTS - If neither exists, ask clarifying questions
Step 2: Clarify Requirements
Ask focused questions about gaps in the input:
- Scope: What's in v1 vs. later? What's explicitly out of scope?
- Users: Who are the primary and secondary users?
- Success: How will you measure if this works?
- Priority: Which requirements are must-have vs. nice-to-have?
Use AskUserQuestion — don't assume. Better to ask than to guess wrong.
Step 3: Write PRD
Write to docs/prds/YYYY-MM-DD-<name>.md using the template in references/prd-template.md.
Key sections:
- Problem Statement — What problem exists and why it matters
- Target Users — Specific user personas, not "all users"
- User Stories — "As a [user], I want to [action] so that [benefit]"
- Requirements — Categorized as Must/Should/Could (MoSCoW)
- Success Metrics — Measurable outcomes
- Out of Scope — Explicit boundaries
Step 4: Review with User
Present the PRD and use AskUserQuestion to confirm:
- Are the requirements complete?
- Is the priority (Must/Should/Could) correct?
- Anything missing or misunderstood?
Output
Save to: docs/prds/YYYY-MM-DD-<name>.md
Next Steps
- Ready for technical design? →
/product-tech-spec - Need to plan implementation? →
/engineer-plan