2 KiB
2 KiB
| name | description |
|---|---|
| prd | Write a Product Requirements Document (PRD). Use when planning a new feature, product, or significant change that needs clear scope, goals, and acceptance criteria before implementation starts. |
PRD (Product Requirements Document) Skill
Use when: starting a new feature, planning a major change, or needing to align on scope before building.
PRD Template
# PRD: [Feature Name]
**Status:** Draft / In Review / Approved
**Author:** [Name]
**Date:** [Date]
**Version:** 1.0
---
## Problem Statement
What problem are we solving? For whom? What's the current pain?
## Goals
- [ ] Goal 1 (measurable)
- [ ] Goal 2 (measurable)
## Non-Goals (explicitly out of scope)
- X is not included in this version
- Y will be addressed in a follow-up
## User Stories
As a [user type], I want to [action] so that [outcome].
### Acceptance Criteria
- Given [context], when [action], then [expected result]
- Given [context], when [action], then [expected result]
## Proposed Solution
High-level description of the approach. NOT detailed implementation — that's for the tech spec.
## UX / Design
- Wireframe or mockup link (if exists)
- Key user flows
- Edge cases and empty states
## Technical Considerations
- Dependencies on other systems
- Performance requirements
- Security/privacy implications
- API contracts needed
## Success Metrics
How will we know this succeeded?
- Metric 1: [what we'll measure, target value]
- Metric 2: [what we'll measure, target value]
## Timeline
- [ ] Design review: [date]
- [ ] Dev kickoff: [date]
- [ ] Alpha/internal: [date]
- [ ] Launch: [date]
## Open Questions
- [ ] Question needing answer before build
- [ ] Dependency on team X decision
Process
- Fill in Problem Statement and Goals first — if you can't articulate these clearly, stop.
- Write Non-Goals explicitly — prevents scope creep.
- Write Acceptance Criteria in Given/When/Then format — these become test cases.
- Review with stakeholders before dev starts.
- Mark open questions and assign owners.