Stats
Actions
Tags
From ai-pm-copilot
Provides PRD templates (lean, comprehensive, Amazon PR/FAQ, Google) for problem statements, metrics, requirements, user stories, and specs. Use for feature documentation and team alignment.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ai-pm-copilot:prd-templatesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Comprehensive PRD (Product Requirements Document) templates and frameworks for documenting product requirements and driving successful execution.
Comprehensive PRD (Product Requirements Document) templates and frameworks for documenting product requirements and driving successful execution.
Auto-loaded by agents:
requirements-engineer - For Amazon PR/FAQ, comprehensive PRD, and lean PRD templatesUse when you need:
We provide 4 ready-to-use PRD templates for different contexts:
Use for: Small features, enhancements, bug fixes Effort: 1-2 hours to write Length: 1-2 pages Audience: Engineering team
Best for:
Template: assets/lean-prd-template.md
Use for: Most features, new capabilities, significant enhancements Effort: 4-8 hours to write Length: 3-5 pages Audience: Cross-functional team
Best for:
Template: assets/comprehensive-prd-template.md
Use for: New products, major bets, working backwards from customer Effort: 8-16 hours to write Length: 3-6 pages (1-2 page PR + 2-4 pages FAQ) Audience: Solo dev or small team (customer-first thinking)
Best for:
Unique approach: Start with the press release announcing the finished product, then answer hard questions. Forces customer-first thinking and addresses risks early.
Template: assets/amazon-pr-faq-template.md
Use for: Data-driven products, cross-team initiatives, scale-focused Effort: 8-12 hours to write Length: 5-10 pages Audience: Cross-functional teams, leadership
Best for:
Unique approach: Emphasizes objectives (goals and non-goals), user benefits, and clear success criteria with measurable targets.
Template: assets/google-prd-template.md
Regardless of template, great PRDs include these key elements:
Purpose: Validate this is worth solving
Include:
Good example: "Small business owners spend 5+ hours per week manually creating invoices, leading to delayed payments and cash flow issues. 68% of survey respondents cited invoicing as their #1 time sink. Current tools require accounting expertise most small business owners lack."
Bad example: "We need an invoicing feature because competitors have one."
Purpose: Define what winning looks like
Include:
Make metrics SMART:
Track both:
Purpose: Validate the problem with data
CRITICAL - Never Fabricate Evidence:
PRDs are specifications Claude Code uses to build features. Fabricated evidence leads to wrong implementations. All included evidence MUST be from real sources.
Include Evidence section ONLY when you have:
If no evidence exists: Omit the Evidence section entirely. Do not use placeholders or template examples as if they were real data.
Valid evidence sources:
competitive-landscape.md (Stage 1), customer-segments.md (Stage 2)Attribution required - All evidence must cite source:
Template examples show FORMAT only:
Check context first:
competitive-landscape.md or customer-segments.md contain feature-relevant dataPurpose: Paint picture of what we're building
Include:
Show, don't just tell:
Purpose: Define what to build
Functional requirements:
Non-functional requirements:
Prioritize ruthlessly:
Purpose: Prevent scope creep and maintain focus
Why it matters:
Include:
Purpose: Define rollout strategy
Include:
Most PRDs start with "what". Great PRDs start with "why".
Poor order: "We're building guest checkout. Users will be able to..." Good order: "Users abandon checkout because account creation adds friction (45% rate). To solve this, we're building..."
Vague language kills PRDs.
Vague → Specific:
Clear documentation serves multiple purposes:
For implementation: Clear requirements, acceptance criteria, non-functional requirements For yourself: User scenarios, flows, edge cases, decisions and rationale For users: Target audience, value proposition, differentiation
Future you needs to know why decisions were made.
Example: "We're starting with web only (no mobile app) because:
Tables for comparisons, diagrams for flows, mockups for UI, charts for data.
A picture is worth a thousand words of requirements.
❌ Solutionizing too early: Start with problem, not "we need to build..." ❌ Vague requirements: "Fast" instead of "< 2 seconds" ❌ Missing acceptance criteria: No clear definition of "done" ❌ No prioritization: Everything is P0 ❌ Scope creep: Adding "just one more thing" repeatedly ❌ Missing success metrics: No way to measure if it worked ❌ No evidence: "I think users want..." instead of data ❌ Too long: 20-page PRDs nobody reads
For solo developers and small teams, PRDs serve as thinking documents and future reference.
Before writing full PRD:
Why this works:
Before finalizing:
Review checklist:
Before submitting your PRD, verify:
Content Completeness:
Quality:
For full checklist: See assets/prd-review-checklist.md
We provide complete, copy-paste-ready templates:
assets/:references/:PRDs aren't always needed:
Skip for:
Use instead:
PRDs make sense when:
Templates are starting points, not rigid structures.
Adapt based on:
Good adaptation:
Bad adaptation:
npx claudepluginhub slgoodrich/agents --plugin ai-pm-copilotGenerates structured Product Requirements Documents (PRDs) using proven PM template. Useful for creating, drafting, or helping with PRDs, product specs, feature specs, or product docs.
Creates professional Product Requirements Documents following a proven template structure. Invoke when writing PRDs, product specs, or feature documentation.
Generates Product Requirements Documents (PRDs) with user stories, success metrics, scope, technical considerations, and risks for product features.