PRD Standards
Purpose
Canonical reference for PRD quality — shared by both authoring and review workflows. Ensures the author and reviewer apply the same standards.
Reference Selection
| Task | Read |
|---|---|
| Writing or reviewing a full PRD | references/prd-template.md |
| Writing or reviewing acceptance criteria | references/acceptance-criteria.md |
| Assessing story readiness or drafting user stories | references/user-story-guide.md |
Relationship to Core Frameworks
4 Risks framework, Confidence Meter (0-10), and OST hierarchy are foundational concepts. This skill operationalizes them in the PRD context — templates, thresholds, and format.
PRD Structure
A discovery-driven PRD follows a standard structure with additive extensions. See references/prd-template.md for the authoritative template.
Core sections (standard PRD):
- Overview (one-line summary, background)
- User Stories
- Functional Requirements (with EARS-format ACs)
- Non-Functional Requirements (including accessibility)
- Success Criteria (tied to Product Outcomes)
- Technical Considerations
Discovery extensions preserve the decisions carried by core sections while adding:
- Hypothesis & validation references in Overview
- 4 Risks confidence per user story
- Unvalidated assumptions section in Technical Considerations
User Story Standards
Each user story follows the persona-grounded format with 4 Risks assessment. See references/user-story-guide.md for the full guide.
Key rules:
- Reference a specific persona from
docs/product/personas/, not generic "user" - Every story has a 4 Risks confidence table with evidence
- "Validated enough" is judged by cost x risk x reversibility, not a fixed threshold
- Remaining risks are documented explicitly, not hidden
Acceptance Criteria Standards
All functional requirements use EARS-format acceptance criteria. See references/acceptance-criteria.md for patterns and examples.
Key rules:
- Use When (event-driven), While (state-driven), or If-Then (conditional) patterns
- Each AC is testable with a clear pass/fail
- User-facing requirements specify each applicable state; an excluded standard state gets a reason only when omission would leave behavior ambiguous
- Accessibility ACs included for UI features