shinpr PRD Standards
Purpose
Canonical reference for PRD quality — shared by both authoring (recipe-define) and review (doc-reviewer) 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 product-principles
4 Risks framework, Confidence Meter (0-10), and OST hierarchy are defined in product-principles. This skill operationalizes them in the PRD context — templates, thresholds, and format. For authoritative definitions, always defer to product-principles.
PRD Structure
A nautilus PRD uses the portions of the standard structure required by its delivery consumer. See references/prd-template.md for the available structure.
Core sections (include when they carry a delivery decision or required evidence):
- Overview (one-line summary, background)
- Users and Stories
- Functional Requirements (with EARS-format ACs)
- Design Context
- Non-Functional Requirements (including accessibility)
- Success Criteria (tied to Product Outcomes)
- Technical Considerations
Nautilus extensions (include at the smallest scope that affects delivery):
- Hypothesis & validation references in Overview
- 4 Risks evidence at the scope that changes delivery readiness
- Design Context derived from design artifacts and prototypes
- Unvalidated assumptions section in Technical Considerations
User Story Standards
User stories remain grounded in an evidenced persona or user distinction. Record 4 Risks evidence at the smallest scope that changes delivery readiness; shared evidence does not need to be repeated per story. See references/user-story-guide.md for the output and readiness rules.
Key rules:
- Reference a specific persona from
docs/product/personas/, not generic "user" - Each material risk has evidence available to the delivery decision
- "Validated enough" is judged by cost x risk x reversibility, not a fixed threshold
- Remaining risks are documented explicitly, not hidden
Acceptance Criteria Standards
Use EARS-format acceptance criteria when its event, state, or conditional form makes the requirement more testable or a downstream consumer requires it. See references/acceptance-criteria.md for selection, quality, and traceability rules.
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 ACs cover relevant states (loading, empty, error, partial, success)
- Accessibility ACs included for UI features