prd-generation

SKILL.md

PRD Generation

Overview

Transform high-level ideas into structured Product Requirements Documents through guided discovery. This skill walks through problem/solution/constraint discovery, generates a professional PRD with measurable goals and user stories, and ensures stakeholder approval before saving.

Announce at start: "I'm using the prd-generation skill to create a Product Requirements Document."

Phase 1: Discovery

Ask these questions ONE AT A TIME (prefer multiple choice where possible).

Do NOT skip discovery. Even if the user provides a detailed brief, confirm understanding by asking at least 3 clarifying questions.

STOP after discovery — present a summary of collected answers and get confirmation before drafting.

Problem Space Questions

# Question Why It Matters
1 What problem does this solve? Anchors the entire PRD
2 Who are the target users? (personas, roles) Shapes user stories
3 How are users currently solving this? Identifies competitive landscape
4 What is the impact of NOT solving this? Justifies priority

Solution Space Questions

# Question Why It Matters
5 What does success look like? (specific metrics) Defines success metrics
6 What are must-have vs nice-to-have features? Sets priority tiers
7 What are the explicit non-goals? Prevents scope creep
8 Are there existing solutions to learn from? Informs design decisions

Constraint Questions

# Question Why It Matters
9 What is the timeline? Any hard deadlines? Scopes release plan
10 What technical constraints exist? Narrows solution space
11 What resources are available? Sets realistic expectations
12 Are there compliance or regulatory requirements? Identifies non-functional reqs

Phase 2: Draft PRD

Generate the PRD using the template below. Dispatch the prd-writer agent with collected answers for heavy generation.

STOP after drafting — do NOT present as final until Phase 3 review is complete.

PRD Template

# [Product/Feature Name] — Product Requirements Document

## 1. Overview
One paragraph summarizing what this is and why it matters.

## 2. Problem Statement
- Current situation
- Pain points
- Impact of not solving

## 3. Goals & Non-Goals
### Goals
- [ ] Goal 1 (measurable)
- [ ] Goal 2 (measurable)

### Non-Goals
- Explicitly NOT doing X
- Explicitly NOT doing Y

## 4. User Stories
As a [persona], I want to [action], so that [benefit].

## 5. Functional Requirements
### FR-1: [Requirement Name]
- Description
- Acceptance criteria
- Priority (P0/P1/P2)

## 6. Non-Functional Requirements
- Performance: [specific targets]
- Security: [requirements]
- Accessibility: [standards]
- Scalability: [expectations]

## 7. Technical Constraints
- Platform/stack requirements
- Integration dependencies
- Data requirements

## 8. Success Metrics
| Metric | Current | Target | How to Measure |
|--------|---------|--------|----------------|

## 9. Timeline & Milestones
| Phase | Description | Target Date |
|-------|-------------|-------------|

## 10. Open Questions
- [ ] Question 1
- [ ] Question 2

## 11. Appendix
References, mockups, related documents

Priority Classification

Priority Meaning Rule
P0 Must-have for launch Without this, the product does not ship
P1 Important, ship soon after launch Significant value but not blocking
P2 Nice-to-have Enhances experience, can wait

Phase 3: Review

Present the PRD section by section:

  1. After each section, ask: "Does this capture your intent? Any changes?"
  2. Revise based on feedback before moving to next section
  3. Pay special attention to these high-signal sections:
    • Goals & Non-Goals (scope alignment)
    • User Stories (persona accuracy)
    • Success Metrics (measurability)
    • Functional Requirements (acceptance criteria completeness)

STOP after review — get explicit "approved" confirmation before saving.

Phase 4: Save and Transition

After explicit approval:

  1. Save to docs/prds/YYYY-MM-DD-<feature>.md
  2. Commit the PRD with message: docs(prd): add PRD for <feature>
  3. If implementation follows, invoke the brainstorming skill
  4. If specs are needed, invoke the spec-writing skill

Transition Decision Table

User Intent Next Skill Rationale
"Let's build this" brainstormingplanning Explore approaches then plan
"Write the specs" spec-writing Break PRD into JTBD specs
"Just save it" None PRD is the deliverable
"Get estimates" task-decomposition Break into estimable tasks

Anti-Patterns / Common Mistakes

Mistake Why It Is Wrong What To Do Instead
Skipping discovery and jumping to draft Produces assumptions-based PRD Always complete Phase 1 first
Goals without metrics Cannot measure success Every goal needs a number
Missing non-goals Scope creep guaranteed Explicitly list what is out of scope
User stories without acceptance criteria Untestable requirements Add Given/When/Then to each story
Generic success metrics ("improve UX") Unmeasurable Use specific numbers: "reduce load time to <2s"
Presenting entire PRD at once for review User overwhelmed, gives superficial approval Present section by section
Copying competitor features verbatim Misses actual user needs Focus on user problems, not solutions

Anti-Rationalization Guards

  • Do NOT skip discovery because "the user already described it well enough"
  • Do NOT leave placeholder text in any section — fill every section or mark as "TBD: [reason]"
  • Do NOT proceed to save without explicit user approval of each section
  • Do NOT invent success metrics — they must come from the user

Integration Points

Skill Relationship
brainstorming Upstream: explores ideas before PRD; downstream: explores implementation after PRD
spec-writing Downstream: PRD provides high-level requirements; specs detail them with JTBD
planning Downstream: plan references PRD requirements for task breakdown
task-decomposition Downstream: breaks PRD into estimable work items
tech-docs-generator Parallel: PRD informs what documentation is needed
acceptance-testing Downstream: acceptance criteria from PRD feed test definitions

Verification Gate

Before claiming the PRD is complete:

  1. VERIFY all 11 sections are filled (not placeholder text)
  2. VERIFY every goal has a measurable metric
  3. VERIFY non-goals are explicit and meaningful
  4. VERIFY user stories have acceptance criteria
  5. VERIFY user has approved each section individually
  6. VERIFY the file is saved and committed

Concrete Example: Discovery Summary

Problem: Users cannot find relevant search results in the dashboard.
Users: Data analysts (primary), team leads (secondary).
Current workaround: Export to Excel and use Ctrl+F.
Impact of not solving: 30min/day wasted per analyst (team of 12).
Success metric: Reduce average search time from 5min to <30s.
Must-have: Full-text search across all dashboard widgets.
Non-goal: Advanced boolean query syntax (P2, not launch).
Timeline: 6 weeks to MVP.
Constraint: Must work with existing Elasticsearch cluster.

This summary is presented to the user for confirmation before Phase 2 begins.

Skill Type

Flexible — Adapt discovery depth and PRD structure to project context while preserving the discovery-before-drafting principle and section-by-section review process.

Weekly Installs
2
First Seen
Today
Installed on
amp2
cline2
opencode2
cursor2
kimi-cli2
warp2