Turn a product idea into a clear PRD for design, engineering, and leadership. — Claude Skill
A Claude Skill for Claude Code by Paweł Huryn — run /write-prd in Claude·Updated Jun 13, 2026·vmain@d384f0c
Creates an eight-section PRD covering context, problem, audience, objective, success metrics, value proposition, solution, release scope, assumptions, and open questions.
- Turns rough feature context into a structured PRD people can review.
- Separates context, problem, objective, customer segment, value proposition, solution, assumptions, and release scope.
- Keeps the writing plain so non-technical stakeholders can understand what is being built and why.
- Makes v1, later scope, success metrics, risks, and open questions explicit before the team estimates work.
- Flags assumptions and measurement gaps before the team treats the PRD as ready.
A PM writes a feature brief with a solution, but the problem, audience, success metric, and release boundaries are fuzzy.
Run /write-prd to turn the idea into a reviewable PRD with measurable goals, assumptions, and a realistic first release.
Who this is for
What it does
Create a complete PRD from a rough product idea and scattered stakeholder notes.
Restructure an existing PRD so the problem, scope, metrics, and assumptions are obvious.
Give design and engineering enough context to challenge scope and estimate implementation.
How it works
Collect the feature idea, target users, business reason, research, constraints, and known risks.
Draft the eight PRD sections: summary, contacts, background, objective, segment, value proposition, solution, and release.
Add measurable key results and explicit assumptions.
Separate first release scope from later improvements so design and engineering can estimate, challenge, and push back.
End with open questions and review decisions so stakeholders know what still needs an answer.
Input options
The product change you are considering and why it matters now.
Example
Idea: improve the team invite flow. Problem: new admins do not invite teammates during setup, and one-user teams rarely activate. Audience: B2B workspace admins in the first 7 days. Evidence: activation 38%, invite completion 41%, week-4 retention 24%, 18 support tickets about invite confusion. Constraint: v1 must fit in 6 weeks.
Build a self-serve invite flow that helps new workspace admins bring teammates into a workspace during setup, so more teams reach collaborative value in the first week.
Teams with one user rarely activate because collaboration never starts. Current activation is 38%, invite completion is 41%, and support saw 18 tickets about invite confusion. The product currently does not make it clear when to invite teammates or why the step matters.
| Metric | Baseline | Target | |---|---:|---:| | Invite completion | 41% | 65% | | Activation within 7 days | 38% | 55% | | Week-4 retention | 24% | 34% | | Setup confusion tickets | 18/month | -30% |
| User | Need | |---|---| | Workspace admin | Know who to invite, why it matters, and whether setup is blocked | | Invited teammate | Understand what they are joining and what to do first | | Support agent | See invite status when helping a stuck admin |
Admins can finish team setup without guessing. They see the next invite action, understand why collaboration matters, and know whether teammates are pending or joined.
Add an onboarding checklist, invite reminder, clearer empty state, invite acceptance tracking, and support-visible event history. The first version should reuse existing roles and permissions.
| Area | Include in v1 | Later | |---|---|---| | Invite flow | checklist, reminder, status | bulk CSV invite | | Permissions | existing roles only | role redesign | | Enterprise setup | basic tracking | SSO provisioning | | Analytics | invite sent, accepted, reminder clicked | full cohort dashboard |
Who owns reminder copy? Should reminders be email, Slack, or both? Which event source is authoritative for activation? What privacy-safe copy should appear for pending invites?
Metrics this improves
Works with
Want to use Product Requirements Document?
Choose how to get started.
Install and run this skill locally on your computer.
Open a terminal on your computer and paste this command:
This downloads the skill with all its files to your computer:
Add -g at the end to make it available in all your projects.
Start Claude Code, then type the command:
Create a Product Requirements Document
Purpose
You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development.
Context
A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders.
Instructions
-
Gather Information: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights.
-
Think Step by Step: Before writing, analyze:
- What problem are we solving?
- Who are we solving it for?
- How will we measure success?
- What are our constraints and assumptions?
-
Apply the PRD Template: Create a document with these 8 sections:
1. Summary (2-3 sentences)
- What is this document about?
2. Contacts
- Name, role, and comment for key stakeholders
3. Background
- Context: What is this initiative about?
- Why now? Has something changed?
- Is this something that just recently became possible?
4. Objective
- What's the objective? Why does it matter?
- How will it benefit the company and customers?
- How does it align with vision and strategy?
- Key Results: How will you measure success? (Use SMART OKR format)
5. Market Segment(s)
- For whom are we building this?
- What constraints exist?
- Note: Markets are defined by people's problems/jobs, not demographics
6. Value Proposition(s)
- What customer jobs/needs are we addressing?
- What will customers gain?
- Which pains will they avoid?
- Which problems do we solve better than competitors?
- Consider the Value Curve framework
7. Solution
- 7.1 UX/Prototypes (wireframes, user flows)
- 7.2 Key Features (detailed feature descriptions)
- 7.3 Technology (optional, only if relevant)
- 7.4 Assumptions (what we believe but haven't proven)
8. Release
- How long could it take?
- What goes in the first version vs. future versions?
- Avoid exact dates; use relative timeframes
-
Use Accessible Language: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.
-
Structure Output: Present the PRD as a well-formatted markdown document with clear headings and sections.
-
Save the Output: If the PRD is substantial (which it will be), save it as a markdown document in the format:
PRD-[product-name].md
Notes
- Be specific and data-driven where possible
- Link each section back to the overall strategy
- Flag assumptions clearly so the team can validate them
- Keep the document concise but complete
Further Reading
Reference documents
name: create-prd description: "Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning. Use when writing a PRD, documenting product requirements, preparing a feature spec, or reviewing an existing PRD."
Create a Product Requirements Document
Purpose
You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development.
Context
A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders.
Instructions
-
Gather Information: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights.
-
Think Step by Step: Before writing, analyze:
- What problem are we solving?
- Who are we solving it for?
- How will we measure success?
- What are our constraints and assumptions?
-
Apply the PRD Template: Create a document with these 8 sections:
1. Summary (2-3 sentences)
- What is this document about?
2. Contacts
- Name, role, and comment for key stakeholders
3. Background
- Context: What is this initiative about?
- Why now? Has something changed?
- Is this something that just recently became possible?
4. Objective
- What's the objective? Why does it matter?
- How will it benefit the company and customers?
- How does it align with vision and strategy?
- Key Results: How will you measure success? (Use SMART OKR format)
5. Market Segment(s)
- For whom are we building this?
- What constraints exist?
- Note: Markets are defined by people's problems/jobs, not demographics
6. Value Proposition(s)
- What customer jobs/needs are we addressing?
- What will customers gain?
- Which pains will they avoid?
- Which problems do we solve better than competitors?
- Consider the Value Curve framework
7. Solution
- 7.1 UX/Prototypes (wireframes, user flows)
- 7.2 Key Features (detailed feature descriptions)
- 7.3 Technology (optional, only if relevant)
- 7.4 Assumptions (what we believe but haven't proven)
8. Release
- How long could it take?
- What goes in the first version vs. future versions?
- Avoid exact dates; use relative timeframes
-
Use Accessible Language: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.
-
Structure Output: Present the PRD as a well-formatted markdown document with clear headings and sections.
-
Save the Output: If the PRD is substantial (which it will be), save it as a markdown document in the format:
PRD-[product-name].md
Notes
- Be specific and data-driven where possible
- Link each section back to the overall strategy
- Flag assumptions clearly so the team can validate them
- Keep the document concise but complete