pm-claude-skills/prd-template/SKILL.md

name, description

name	description
prd-template	Product Requirements Document creation following proven PM template structure. Use when the user asks to create, write, draft, or help with a PRD, product requirements document, product spec, feature specification, or product documentation for a new feature or product.

PRD Template Skill

This skill helps create professional Product Requirements Documents following industry best practices.

Template Structure

Every PRD should include these sections in order:

1. Overview

• Problem Statement: What problem are we solving? (2-3 sentences)
• Proposed Solution: High-level description of what we're building (2-3 sentences)
• Success Metrics: How we'll measure success (3-5 key metrics)

2. Context & Background

• Why Now: Why is this the right time?
• Strategic Alignment: How does this align with company objectives?
• User Research Summary: Key insights from research (if applicable)

3. User Stories & Use Cases

Format: "As a [user type], I want to [action] so that [benefit]"

• Include 3-7 primary user stories
• Add acceptance criteria for each

4. Requirements

Functional Requirements:

• Must-have features (P0)
• Should-have features (P1)
• Nice-to-have features (P2)

Non-Functional Requirements:

• Performance expectations
• Security considerations
• Accessibility requirements

5. Design & User Experience

• Link to design mocks or wireframes
• Key user flows
• Edge cases and error states

6. Technical Considerations

• Architecture implications
• Dependencies on other systems
• Technical risks and mitigations

7. Implementation Plan

• Phase 1 (MVP): What goes in first version
• Phase 2: What comes next
• Phase 3: Future enhancements

8. Open Questions

• Decisions that still need to be made
• Stakeholders to consult
• Research needed

9. Appendix

• Research links
• Related documents
• Competitive analysis

Writing Guidelines

Tone: Clear, concise, actionable Audience: Engineers, designers, stakeholders Length: Aim for 3-6 pages for features, 8-12 for products

Best Practices:

• Use concrete examples over abstractions
• Include "why" not just "what"
• Make requirements testable
• Link to supporting materials
• Update as decisions are made

What Makes a Good PRD

✅ Do:

• Write from the user's perspective
• Include specific success metrics
• Address edge cases
• Link to research and data
• Make trade-offs explicit

❌ Don't:

• Write implementation details (that's tech spec)
• Assume everyone has context
• Leave requirements ambiguous
• Skip the "why"
• Forget about accessibility

Example PRD Opening