/prd-generator
Generate comprehensive Product Requirements Documents (PRDs) for product managers. Use this skill when users ask to "create a PRD", "write product requirements", "document a feature", or need help structuring product specifications.
$ npx -y skills add jamesrochabrun/skills --skill prd-generator --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/prd-generator
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate comprehensive Product Requirements Documents (PRDs) for product managers. Use this skill when users ask to "create a PRD", "write product requirements", "document a feature", or need help structuring product specifications.
SKILL.md
prd-generator.SKILL.mdname: prd-generator
description: Generate comprehensive Product Requirements Documents (PRDs) for product managers. Use this skill when users ask to "create a PRD", "write product requirements", "document a feature", or need help structuring product specifications.
PRD Generator
Overview
Generate comprehensive, well-structured Product Requirements Documents (PRDs) that follow industry best practices. This skill helps product managers create clear, actionable requirements documents that align stakeholders and guide development teams.
Core Workflow
When a user requests to create a PRD (e.g., "create a PRD for a user authentication feature"), follow this workflow:
Step 1: Gather Context
Before generating the PRD, collect essential information through a discovery conversation:
**Required Information:**
- **Feature/Product Name**: What are we building?
- **Problem Statement**: What problem does this solve?
- **Target Users**: Who is this for?
- **Business Goals**: What are we trying to achieve?
- **Success Metrics**: How will we measure success?
- **Timeline/Constraints**: Any deadlines or limitations?
**Discovery Questions to Ask:**
1. What problem are you trying to solve?
2. Who is the primary user/audience for this feature?
3. What are the key business objectives?
4. Are there any technical constraints we should be aware of?
5. What does success look like? How will you measure it?
6. What's the timeline for this feature?
7. What's explicitly out of scope?
**Note:** If the user provides a detailed brief or requirements upfront, you can skip some questions. Always ask for clarification on missing critical information.
Step 2: Generate PRD Structure
Use the standard PRD template from `references/prd_template.md` to create a well-structured document. The PRD should include:
1. **Executive Summary** - High-level overview (2-3 paragraphs) 2. **Problem Statement** - Clear articulation of the problem 3. **Goals & Objectives** - What we're trying to achieve 4. **User Personas** - Who we're building for 5. **User Stories & Requirements** - Detailed functional requirements 6. **Success Metrics** - KPIs and measurement criteria 7. **Scope** - What's in and out of scope 8. **Technical Considerations** - Architecture, dependencies, constraints 9. **Design & UX Requirements** - UI/UX considerations 10. **Timeline & Milestones** - Key dates and phases 11. **Risks & Mitigation** - Potential issues and solutions 12. **Dependencies & Assumptions** - What we're relying on 13. **Open Questions** - Unresolved items
Step 3: Create User Stories
For each major requirement, generate user stories using the standard format:
As a [user type],
I want to [action],
So that [benefit/value].
Acceptance Criteria:
- [Specific, testable criterion 1]
- [Specific, testable criterion 2]
- [Specific, testable criterion 3]
Reference `references/user_story_examples.md` for common patterns and best practices.
Step 4: Define Success Metrics
Use appropriate metrics frameworks based on the product type:
- **AARRR (Pirate Metrics)**: Acquisition, Activation, Retention, Revenue, Referral
- **HEART Framework**: Happiness, Engagement, Adoption, Retention, Task Success
- **North Star Metric**: Single key metric that represents core value
- **OKRs**: Objectives and Key Results
Consult `references/metrics_frameworks.md` for detailed guidance on each framework.
Step 5: Validate & Review
Optionally run the validation script to ensure PRD completeness:
scripts/validate_prd.sh <prd_file.md>
This checks for:
- All required sections present
- User stories follow proper format
- Success metrics are defined
- Scope is clearly articulated
- No placeholder text remains
Usage Patterns
Pattern 1: New Feature PRD
**User Request:** "Create a PRD for adding dark mode to our mobile app"
**Execution:**
1. Ask discovery questions about dark mode requirements 2. Generate PRD using template 3. Create user stories for:
- Theme switching
- Preference persistence
- System-level sync
- Design token updates
4. Define success metrics (adoption rate, user satisfaction) 5. Identify technical dependencies (design system, platform APIs)
Pattern 2: Product Enhancement PRD
**User Request:** "Write requirements for improving our search functionality"
**Execution:**
1. Gather context on current search limitations 2. Identify user pain points and desired improvements 3. Generate PRD with focus on:
- Current state analysis
- Proposed enhancements
- Impact assessment
4. Create prioritized user stories 5. Define before/after metrics
Pattern 3: New Product PRD
**User Request:** "I need a PRD for a new analytics dashboard product"
**Execution:**
1. Comprehensive discovery (market analysis, user research) 2. Generate full PRD with:
- Market opportunity
- Competitive analysis
- Product vision
- MVP scope
- Go-to-market considerations
3. Detailed user stories for core features 4. Phased rollout plan 5. Success metrics aligned with business goals
Pattern 4: Quick PRD / One-Pager
**User Request:** "Create a lightweight PRD for a small bug fix feature"
**Execution:**
1. Generate simplified PRD focusing on:
- Problem statement
- Solution approach
- Acceptance criteria
- Success metrics
2. Skip sections not relevant for small scope 3. Keep document concise (1-2 pages)
PRD Best Practices
Writing Quality Requirements
**Good Requirements Are:**
- **Specific**: Clear and unambiguous
- **Measurable**: Can be verified/tested
- **Achievable**: Technically feasible
- **Relevant**: Tied to user/business value
- **Time-bound**: Has clear timeline
**Avoid:**
- Vague language ("fast", "easy", "intuitive")
- Implementation details (let engineers decide how)
- Feature creep (stick to core requirements)
- Assumptions without validation
User Story Best Practices
**DO:**
- Focus on user value, not features
- Write fro
Read more
name: prd-generator description: Generate comprehensive Product Requirements Documents (PRDs) for product managers. Use this skill when users ask to "create a PRD", "write product requirements", "document a feature", or need help structuring product specifications.
PRD Generator
Overview
Generate comprehensive, well-structured Product Requirements Documents (PRDs) that follow industry best practices. This skill helps product managers create clear, actionable requirements documents that align stakeholders and guide development teams.
Core Workflow
When a user requests to create a PRD (e.g., "create a PRD for a user authentication feature"), follow this workflow:
Step 1: Gather Context
Before generating the PRD, collect essential information through a discovery conversation:
**Required Information:**
- **Feature/Product Name**: What are we building?
- **Problem Statement**: What problem does this solve?
- **Target Users**: Who is this for?
- **Business Goals**: What are we trying to achieve?
- **Success Metrics**: How will we measure success?
- **Timeline/Constraints**: Any deadlines or limitations?
**Discovery Questions to Ask:**
1. What problem are you trying to solve? 2. Who is the primary user/audience for this feature? 3. What are the key business objectives? 4. Are there any technical constraints we should be aware of? 5. What does success look like? How will you measure it? 6. What's the timeline for this feature? 7. What's explicitly out of scope?
**Note:** If the user provides a detailed brief or requirements upfront, you can skip some questions. Always ask for clarification on missing critical information.
Step 2: Generate PRD Structure
Use the standard PRD template from `references/prd_template.md` to create a well-structured document. The PRD should include:
1. **Executive Summary** - High-level overview (2-3 paragraphs) 2. **Problem Statement** - Clear articulation of the problem 3. **Goals & Objectives** - What we're trying to achieve 4. **User Personas** - Who we're building for 5. **User Stories & Requirements** - Detailed functional requirements 6. **Success Metrics** - KPIs and measurement criteria 7. **Scope** - What's in and out of scope 8. **Technical Considerations** - Architecture, dependencies, constraints 9. **Design & UX Requirements** - UI/UX considerations 10. **Timeline & Milestones** - Key dates and phases 11. **Risks & Mitigation** - Potential issues and solutions 12. **Dependencies & Assumptions** - What we're relying on 13. **Open Questions** - Unresolved items
Step 3: Create User Stories
For each major requirement, generate user stories using the standard format:
As a [user type], I want to [action], So that [benefit/value]. Acceptance Criteria: - [Specific, testable criterion 1] - [Specific, testable criterion 2] - [Specific, testable criterion 3]
Reference `references/user_story_examples.md` for common patterns and best practices.
Step 4: Define Success Metrics
Use appropriate metrics frameworks based on the product type:
- **AARRR (Pirate Metrics)**: Acquisition, Activation, Retention, Revenue, Referral
- **HEART Framework**: Happiness, Engagement, Adoption, Retention, Task Success
- **North Star Metric**: Single key metric that represents core value
- **OKRs**: Objectives and Key Results
Consult `references/metrics_frameworks.md` for detailed guidance on each framework.
Step 5: Validate & Review
Optionally run the validation script to ensure PRD completeness:
scripts/validate_prd.sh <prd_file.md>
This checks for:
- All required sections present
- User stories follow proper format
- Success metrics are defined
- Scope is clearly articulated
- No placeholder text remains
Usage Patterns
Pattern 1: New Feature PRD
**User Request:** "Create a PRD for adding dark mode to our mobile app"
**Execution:**
1. Ask discovery questions about dark mode requirements 2. Generate PRD using template 3. Create user stories for:
- Theme switching
- Preference persistence
- System-level sync
- Design token updates
4. Define success metrics (adoption rate, user satisfaction) 5. Identify technical dependencies (design system, platform APIs)
Pattern 2: Product Enhancement PRD
**User Request:** "Write requirements for improving our search functionality"
**Execution:**
1. Gather context on current search limitations 2. Identify user pain points and desired improvements 3. Generate PRD with focus on:
- Current state analysis
- Proposed enhancements
- Impact assessment
4. Create prioritized user stories 5. Define before/after metrics
Pattern 3: New Product PRD
**User Request:** "I need a PRD for a new analytics dashboard product"
**Execution:**
1. Comprehensive discovery (market analysis, user research) 2. Generate full PRD with:
- Market opportunity
- Competitive analysis
- Product vision
- MVP scope
- Go-to-market considerations
3. Detailed user stories for core features 4. Phased rollout plan 5. Success metrics aligned with business goals
Pattern 4: Quick PRD / One-Pager
**User Request:** "Create a lightweight PRD for a small bug fix feature"
**Execution:**
1. Generate simplified PRD focusing on:
- Problem statement
- Solution approach
- Acceptance criteria
- Success metrics
2. Skip sections not relevant for small scope 3. Keep document concise (1-2 pages)
PRD Best Practices
Writing Quality Requirements
**Good Requirements Are:**
- **Specific**: Clear and unambiguous
- **Measurable**: Can be verified/tested
- **Achievable**: Technically feasible
- **Relevant**: Tied to user/business value
- **Time-bound**: Has clear timeline
**Avoid:**
- Vague language ("fast", "easy", "intuitive")
- Implementation details (let engineers decide how)
- Feature creep (stick to core requirements)
- Assumptions without validation
User Story Best Practices
**DO:**
- Focus on user value, not features
- Write fro
A comprehensive plugin and marketplace for Claude Code containing 24 custom skills across engineering, Apple development, product management, design, content, trading, database, QA, educational, and AI architecture domains.
Repo: jamesrochabrun/skills
Other skills on jamesrochabrun-skills.
- /anthropic-architect
Determine the best Anthropic architecture for your project by analyzing requirements and recommending the optimal combination of Skills, Agents, Prompts, and SDK primitives.
Open skill - /anthropic-prompt-engineer
Master Anthropic's prompt engineering techniques to generate new prompts or improve existing ones using best practices for Claude AI models.
Open skill - /apple-hig-designer
Design iOS apps following Apple's Human Interface Guidelines. Generate native components, validate designs, and ensure accessibility compliance for iPhone, iPad, and Apple Watch.
Open skill - /book-illustrator
Expert children's book illustrator guide with 2024-2025 best practices, focusing on age-appropriate styles, color theory, character design, and visual storytelling for kids books that captivate young readers.
Open skill - /content-brief-generator
Generate comprehensive content briefs for writers, ensuring clarity, alignment, and strategic content creation across all formats.
Open skill - /design-brief-generator
Generate comprehensive design briefs for design projects. Use this skill when designers ask to "create a design brief", "structure a design project", "define design requirements", or need help planning design work.
Open skill

