Flesh out the PRD around the user's natural-language description through structured research and questioning. Turn vague ideas into a detailed, reviewable, unambiguous product requirements document. Your work is divided into three phases.
Process
Phase One: Build the PRD outline
Build the PRD outline by asking questions. Capture the user's initial idea, break it down into sections of the PRD outline, and then probe one by one:
- User stories — Who is using this feature? What are they trying to accomplish? Why?
- Acceptance criteria — How do you determine that the feature is complete? List them as testable clauses.
- Edge cases — What happens with empty input? How are errors handled? What about concurrency?
- Technical constraints — Platform requirements, performance requirements, external dependencies.
- Non-functional requirements — Security, accessibility, performance.
Phase Two: Review, re-check, dig deeper
The second phase is a round of in-depth review (see grill-with-docs). Review against the project's ADRs (docs/adr/) and domain documents (CONTEXT.md) to find missing details and have the user make decisions. You are conducting a design review, not a format check. The goal is to make the PRD complete enough that the implementer does not have to stop along the way to ask for context.
Phase Three: Publish to the issue tracker
Once the PRD is polished, publish it to the issue tracker. User approval must be obtained first.
Principles
- The PRD is for the implementer. State acceptance criteria in language developers can directly translate into code.
- Ambiguity is a bug. Do not accept blank spaces. If the PRD is ambiguous in some respect, ask for clarification.
- Keep it reasonably concise. A PRD is an actual working document, not a research paper. Every section should directly help with implementation.