Create a Product Requirements Document skill

Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning.

by phuryn·MIT license·★ 26,557 Stars on the repo·GitHub ↗

Use now

Files of Create a Product Requirements Document

phuryn/main1 file shown
SKILL.md
Show the full text87 lines

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

  1. 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.

  2. 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?
  3. 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
  4. Use Accessible Language: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.

  5. Structure Output: Present the PRD as a well-formatted markdown document with clear headings and sections.

  6. 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
1---
2name: create-prd
3description: "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."
4---
5 
6# Create a Product Requirements Document
7 
8## Purpose
9 
10You 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.
11 
12## Context
13 
14A 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.
15 
16## Instructions
17 
181. **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.
19 
202. **Think Step by Step**: Before writing, analyze:
21 - What problem are we solving?
22 - Who are we solving it for?
23 - How will we measure success?
24 - What are our constraints and assumptions?
25 
263. **Apply the PRD Template**: Create a document with these 8 sections:
27 
28 **1. Summary** (2-3 sentences)
29 - What is this document about?
30 
31 **2. Contacts**
32 - Name, role, and comment for key stakeholders
33 
34 **3. Background**
35 - Context: What is this initiative about?
36 - Why now? Has something changed?
37 - Is this something that just recently became possible?
38 
39 **4. Objective**
40 - What's the objective? Why does it matter?
41 - How will it benefit the company and customers?
42 - How does it align with vision and strategy?
43 - Key Results: How will you measure success? (Use SMART OKR format)
44 
45 **5. Market Segment(s)**
46 - For whom are we building this?
47 - What constraints exist?
48 - Note: Markets are defined by people's problems/jobs, not demographics
49 
50 **6. Value Proposition(s)**
51 - What customer jobs/needs are we addressing?
52 - What will customers gain?
53 - Which pains will they avoid?
54 - Which problems do we solve better than competitors?
55 - Consider the Value Curve framework
56 
57 **7. Solution**
58 - 7.1 UX/Prototypes (wireframes, user flows)
59 - 7.2 Key Features (detailed feature descriptions)
60 - 7.3 Technology (optional, only if relevant)
61 - 7.4 Assumptions (what we believe but haven't proven)
62 
63 **8. Release**
64 - How long could it take?
65 - What goes in the first version vs. future versions?
66 - Avoid exact dates; use relative timeframes
67 
684. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.
69 
705. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections.
71 
726. **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`
73 
74## Notes
75 
76- Be specific and data-driven where possible
77- Link each section back to the overall strategy
78- Flag assumptions clearly so the team can validate them
79- Keep the document concise but complete
80 
81---
82 
83### Further Reading
84 
85- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template)
86- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template)
87 

Discussion

Alternatives

Academy guideStop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: "how do I", "how can I", "getting started with", "what can Claude do", "teach me", "learn to use"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.Business & ops · Apache-2.0Analyze feature requestsAnalyze and prioritize a list of feature requests by theme, strategic alignment, impact, effort, and risk. Use when reviewing customer feature requests, triaging a backlog, or making prioritization decisions. · MITAdvocacy program designerUse when the user asks to "design an employee advocacy program", "set up founder-led sharing", or "build a share kit for the team"; produces an advocacy program blueprint in two modes — participation-driven opt-in (default) or top-down assigned with its coercion and authenticity risks flagged — with a voluntary opt-in roster spec submitted as channel-registry proposal events, share kits with mandatory per-person variation, staggered human posting windows plus anti-pod guardrails (no coordinated identical reshares, no engagement rings), per-person material-connection disclosure lines per FTC and 《互联网广告管理办法》, and a Slack/Teams distribution spec. Not for paid creator campaigns — use campaign-planner. 员工倡导/创始人IP分享/内部分享计划/披露合规Business & ops · Apache-2.0Act as a product managerGuides the AI to act as a product manager, assisting in writing product requirement documents and addressing product-related queries.Business & ops · CC0-1.0