Turn a product idea into a clear PRD for design, engineering, and leadership. — Claude Skill
A Claude Skill for Claude Code by Pawel 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 teams with one user rarely activate. Audience: B2B workspace admins in the first 7 days. Evidence: 38% activation, 24% week-4 retention, invite completion 41%, 18 support tickets mention invite confusion, 12 customers asked for Slack invite reminders. Business goal: improve activation this quarter without increasing Support load. Constraint: first release must fit in 6 weeks with 2 engineers and one designer.
Build a self-serve invite flow that helps new admins bring teammates into a workspace during setup. The PRD focuses on the first 7 days after workspace creation, where invite completion is the strongest signal tied to activation.
B2B workspace admins often create a workspace alone and miss the invite step. Teams with one user rarely activate because there is no collaboration loop. Primary audience: new workspace admins. Secondary audience: invited teammates who need a simple way to accept and join.
Objective: help new admins invite the right teammates before setup stalls. Success: activation rises from 38% to 55%, invite completion rises from 41% to 65%, setup-related support tickets drop by 30%, and week-4 retention improves from 24% to 32%.
Include an in-app setup checklist, invite reminder option, clearer empty state when no teammate has joined, admin confirmation screen, and event tracking for invite sent, invite accepted, and setup completed.
Exclude bulk CSV import, full role-permission redesign, SSO setup wizard, and account-level provisioning from v1. These may matter for enterprise customers, but they are not required to test whether invite completion improves activation.
Assumptions: admins know whom to invite; reminders are acceptable in the first week; activation improves when a second teammate joins before day 7. Risks: reminder fatigue, unclear ownership between admin and teammate, and missing tracking for invite acceptance.
Who owns Slack reminder copy? Should reminders be email, Slack, or both? What is the privacy-safe wording for pending invites? Which event source is authoritative for activation reporting?
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