PRD Writer Skill
Generate a complete, structured PRD from a feature idea, problem statement, or brief description.
When to Use
- User needs to write a PRD for a new feature
- User has an idea and wants it turned into a structured spec
- User says
/prd-writer followed by a feature description
- Any time a product requirement needs to be documented
Framework: PRD Structure
1. Overview
- Feature name: Clear, descriptive name
- Author: [to be filled]
- Date: Current date
- Status: Draft / In Review / Approved
- One-liner: What this feature does in one sentence
2. Problem Statement
- What problem are we solving? Describe the user pain point or business need
- Who has this problem? Primary user segment
- How big is this problem? Estimated impact (users affected, frequency, severity)
- Why solve it now? Urgency, strategic alignment, competitive pressure
3. Goals & Non-Goals
Goals:
- 3-5 specific, measurable goals this feature should achieve
- Each goal maps to a user need or business objective
Non-Goals:
- Explicitly list what this feature will NOT do
- Prevents scope creep and sets expectations
4. User Stories
Write 3-5 user stories in the format:
As a [user type], I want to [action] so that [benefit].
Include acceptance criteria for each:
- Given [context], when [action], then [expected result]
5. Detailed Requirements
Functional Requirements:
| ID |
Requirement |
Priority (P0/P1/P2) |
Notes |
| FR-1 |
|
|
|
| FR-2 |
|
|
|
Non-Functional Requirements:
- Performance: Latency, throughput, scalability targets
- Security: Auth, data handling, compliance
- Accessibility: WCAG level, screen reader support
- Reliability: Uptime, error handling, graceful degradation
For AI/ML features, also include:
- Model requirements: Accuracy, latency, cost per inference
- Data requirements: Training data, eval data, data pipeline
- Safety requirements: Content policy, guardrails, fallback behavior
- Eval criteria: How model quality will be measured
6. UX & Design
- User flow: Step-by-step walkthrough of the primary flow
- Key screens/states: Describe the main UI states (loading, empty, error, success)
- Edge cases: What happens when things go wrong?
- Design references: Links to mockups/wireframes (placeholder)
7. Technical Approach
- Architecture: High-level system design
- Dependencies: APIs, services, teams needed
- Data model: Key entities and relationships
- Migration: Any data migration or backward compatibility concerns
8. Success Metrics
- Primary metric: The one number that tells us this feature worked
- Secondary metrics (3-4): Supporting indicators
- Guardrail metrics (2-3): What must NOT regress
- Measurement plan: How and when to measure
9. Launch Plan
- Rollout strategy: Feature flag → internal → beta → GA
- Launch criteria: What must be true before each stage
- Rollback plan: How to revert if something goes wrong
- Communication: Who needs to know and when
10. Open Questions
- List unresolved questions that need stakeholder input
- Include who should answer each question
Output Format
Generate as clean markdown, ready to paste into Notion, Confluence, Google Docs, or any doc tool. Use tables for requirements. Be specific and actionable — avoid vague language.
Research-First Workflow
- Research — Search for comparable features from competitors, best practices, and relevant technical approaches.
- Generate the complete PRD following the structure above.
- Flag open questions and assumptions that need validation.
1---2name: prd-writer3description: Generate structured Product Requirements Documents (PRDs) from a feature brief, idea, or problem statement. Covers problem definition, user stories, requirements, success metrics, and launch plan. Adapts to AI/ML product contexts.4---56# PRD Writer Skill78Generate a complete, structured PRD from a feature idea, problem statement, or brief description.910## When to Use11- User needs to write a PRD for a new feature12- User has an idea and wants it turned into a structured spec13- User says `/prd-writer` followed by a feature description14- Any time a product requirement needs to be documented1516## Framework: PRD Structure1718### 1. Overview19- **Feature name**: Clear, descriptive name20- **Author**: [to be filled]21- **Date**: Current date22- **Status**: Draft / In Review / Approved23- **One-liner**: What this feature does in one sentence2425### 2. Problem Statement26- **What problem are we solving?** Describe the user pain point or business need27- **Who has this problem?** Primary user segment28- **How big is this problem?** Estimated impact (users affected, frequency, severity)29- **Why solve it now?** Urgency, strategic alignment, competitive pressure3031### 3. Goals & Non-Goals3233**Goals:**34- 3-5 specific, measurable goals this feature should achieve35- Each goal maps to a user need or business objective3637**Non-Goals:**38- Explicitly list what this feature will NOT do39- Prevents scope creep and sets expectations4041### 4. User Stories42Write 3-5 user stories in the format:43> As a [user type], I want to [action] so that [benefit].4445Include acceptance criteria for each:46- Given [context], when [action], then [expected result]4748### 5. Detailed Requirements4950**Functional Requirements:**51| ID | Requirement | Priority (P0/P1/P2) | Notes |52|----|------------|---------------------|-------|53| FR-1 | | | |54| FR-2 | | | |5556**Non-Functional Requirements:**57- Performance: Latency, throughput, scalability targets58- Security: Auth, data handling, compliance59- Accessibility: WCAG level, screen reader support60- Reliability: Uptime, error handling, graceful degradation6162**For AI/ML features, also include:**63- Model requirements: Accuracy, latency, cost per inference64- Data requirements: Training data, eval data, data pipeline65- Safety requirements: Content policy, guardrails, fallback behavior66- Eval criteria: How model quality will be measured6768### 6. UX & Design69- **User flow**: Step-by-step walkthrough of the primary flow70- **Key screens/states**: Describe the main UI states (loading, empty, error, success)71- **Edge cases**: What happens when things go wrong?72- **Design references**: Links to mockups/wireframes (placeholder)7374### 7. Technical Approach75- **Architecture**: High-level system design76- **Dependencies**: APIs, services, teams needed77- **Data model**: Key entities and relationships78- **Migration**: Any data migration or backward compatibility concerns7980### 8. Success Metrics81- **Primary metric**: The one number that tells us this feature worked82- **Secondary metrics** (3-4): Supporting indicators83- **Guardrail metrics** (2-3): What must NOT regress84- **Measurement plan**: How and when to measure8586### 9. Launch Plan87- **Rollout strategy**: Feature flag → internal → beta → GA88- **Launch criteria**: What must be true before each stage89- **Rollback plan**: How to revert if something goes wrong90- **Communication**: Who needs to know and when9192### 10. Open Questions93- List unresolved questions that need stakeholder input94- Include who should answer each question9596## Output Format97Generate as clean markdown, ready to paste into Notion, Confluence, Google Docs, or any doc tool. Use tables for requirements. Be specific and actionable — avoid vague language.9899## Research-First Workflow1001. **Research** — Search for comparable features from competitors, best practices, and relevant technical approaches.1012. **Generate** the complete PRD following the structure above.1023. **Flag** open questions and assumptions that need validation.
aroyburman-codes