--- 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.