76 lines
2 KiB
Markdown
76 lines
2 KiB
Markdown
|
---
|
||
|
|
name: prd
|
||
|
|
description: 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
|
||
|
|
|
||
|
|
```markdown
|
||
|
|
# 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
|
||
|
|
1. Fill in Problem Statement and Goals first — if you can't articulate these clearly, stop.
|
||
|
|
2. Write Non-Goals explicitly — prevents scope creep.
|
||
|
|
3. Write Acceptance Criteria in Given/When/Then format — these become test cases.
|
||
|
|
4. Review with stakeholders before dev starts.
|
||
|
|
5. Mark open questions and assign owners.
|