| name | description | license | metadata | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
create-prd |
PRD scaffolding expert that generates structured product requirements documents using an 8-section framework. |
MIT + Commons Clause |
|
Structured product requirements document creation using a proven 8-section framework. This skill produces clear, jargon-free PRDs that communicate what to build, why it matters, and how success is measured. Every PRD generated follows a consistent structure that keeps engineering, design, and business stakeholders aligned.
- New Product Initiative -- Starting a product from scratch and need a comprehensive spec before development begins.
- Feature Expansion -- Adding significant functionality to an existing product that requires cross-team alignment.
- Stakeholder Alignment -- Need a single document that answers "what are we building and why?" for everyone involved.
Write 2-3 sentences that a busy executive can read in 10 seconds and understand the full scope. Answer three questions: What is this? Who is it for? Why are we doing it now?
Do not use marketing language. State the product, the user, and the expected outcome plainly.
A table of people involved in the decision:
| Name | Role | Responsibility |
|---|---|---|
| ... | Product Manager | Final decision on scope |
| ... | Engineering Lead | Technical feasibility |
| ... | Design Lead | UX direction |
| ... | Stakeholder | Business approval |
Keep this short. Only list people who will actively contribute or approve.
Answer three questions:
- Context -- What is the current state? What exists today?
- Why now? -- What changed in the market, technology, or business that makes this urgent?
- What recently became possible? -- New capabilities, partnerships, data, or insights that enable this initiative.
This section sets the stage. A reader who skips every other section should still understand the motivation after reading Background.
State the business benefit and the customer benefit separately:
- Business benefit: How does this move a business metric? (revenue, retention, cost reduction, market share)
- Customer benefit: How does this improve the user's life? (time saved, friction removed, new capability)
Then define 2-4 SMART Key Results in OKR format:
- Objective: [qualitative, inspirational statement]
- KR1: [metric] from [current] to [target] by [date]
- KR2: [metric] from [current] to [target] by [date]
- KR3: [metric] from [current] to [target] by [date]
Define segments by the problems they face or jobs they need done -- not by demographics. A segment is a group of people who share a common struggle or desired outcome.
Format: "[Segment name]: People who need to [job/problem] because [context]."
Bad: "Millennials aged 25-35 in urban areas" Good: "Time-constrained professionals who need to coordinate schedules across 3+ tools because their organization lacks a unified calendar system"
For each market segment, define:
- Jobs addressed -- What tasks or goals does this product help accomplish?
- Gains created -- What positive outcomes does the user experience?
- Pains relieved -- What frustrations, risks, or obstacles are removed?
- Competitive advantage -- Why is our approach better than existing alternatives?
Use the Value Curve framework to visualize where you compete, where you exceed, and where you deliberately underinvest relative to alternatives.
Break into subsections:
- UX / Prototypes -- Key screens, flows, or interaction patterns. Link to design files.
- Key Features -- Numbered list of features with one-sentence descriptions. Mark each as P0 (must-have), P1 (important), or P2 (nice-to-have).
- Technology (optional) -- Architecture decisions, integrations, or infrastructure requirements that constrain the solution.
- Assumptions -- Explicit list of things you believe to be true but have not validated. Each assumption should have a plan to validate it.
- Relative timeline -- Use T-shirt sizes (S/M/L/XL) or Now/Next/Later rather than specific dates, unless dates are firm.
- v1 scope -- What ships in the first version? Draw a clear line.
- Future versions -- What is explicitly deferred? List it so stakeholders know it was considered but intentionally excluded.
- Success criteria -- When do we know v1 succeeded? Reference the Key Results from Section 4.
- Plain language -- No jargon, no acronyms without definition, no buzzwords.
- One idea per sentence -- If a sentence has "and" connecting two distinct ideas, split it.
- Specificity over abstraction -- "Reduce onboarding from 12 steps to 4" beats "Simplify onboarding."
- Saved as:
PRD-[product-name].md
- Gather context: product name, target segment, core problem.
- Run
scripts/prd_scaffolder.pyto generate the skeleton. - Fill in each section using the guidance above and
references/prd-writing-guide.md. - Review against the checklist in
references/prd-writing-guide.md. - Share with stakeholders for feedback.
| Tool | Purpose | Command |
|---|---|---|
prd_scaffolder.py |
Generate PRD skeleton | python scripts/prd_scaffolder.py --product-name "MyProduct" --objective "Short description" --segments "Segment A, Segment B" |
references/prd-writing-guide.md-- Section-by-section writing guide and review checklistassets/prd_template.md-- Complete PRD template ready to fill in