PRD Generation Skill

Expert guidance for creating clear, actionable Product Requirements Documents.

When to Use

• User asks to create a PRD
• User wants to plan a feature
• User needs to write specifications
• User mentions "requirements document"

PRD Quality Checklist

User Stories Must Be:

• Small: Completable in one focused session
• Independent: No dependencies on later stories
• Verifiable: Clear acceptance criteria

Acceptance Criteria Must Be:

• Specific: Not vague ("works correctly" is bad)
• Testable: Can be checked programmatically or visually
• Complete: Include typecheck/lint requirements

Structure Must Include:

1. Introduction/Overview
2. Goals (measurable)
3. User Stories (with acceptance criteria)
4. Functional Requirements (numbered)
5. Non-Goals (explicit scope boundaries)
6. Technical Considerations (if relevant)
7. Success Metrics

Story Sizing Guide

Right Size (1 iteration):

• Add a database column
• Create a single component
• Implement one API endpoint
• Add form validation

Too Big (split it):

• "Build the dashboard" -> schema + queries + UI + filters
• "Add authentication" -> schema + middleware + login + sessions
• "Refactor the API" -> one story per endpoint

Question Framework

Ask 3-5 clarifying questions with options:

1. What problem does this solve?
   A. [Option]
   B. [Option]
   C. Other: [specify]

2. Who is the target user?
   A. [Option]
   B. [Option]

Allow "1A, 2B" style responses for efficiency.

Output Location

Save to: tasks/prd-[feature-name].md