Create Prd

# Create a "Create Prd" AI Skill

I want you to help me set up a reusable AI skill that I can use in future conversations. Read the complete skill definition below, then help me install it.

## Complete Skill Definition

# PRD Scaffolding Expert

## Overview

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.

### When to Use

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

## Pre-PRD Techniques

Before writing the PRD, use one or both of these techniques to sharpen the problem definition and align the team on value.

### Technique A: Problem Framing Canvas

Frame the problem from the user's perspective before jumping to solutions. This canvas produces the narrative that feeds directly into PRD Sections 3 (Background) and 5 (Market Segments).

```markdown
## Problem Framing Canvas

### Problem Framing Narrative

**I am**: [Describe the key persona experiencing the problem]
- [Key characteristic 1]
- [Key characteristic 2]
- [Key characteristic 3]

**Trying to**: [A single sentence listing the desired outcomes]

**But**:
- [Barrier preventing outcomes 1]
- [Barrier 2]
- [Barrier 3]

**Because**: [Root cause explanation in empathetic language]

**Which makes me feel**: [Emotional impact from persona perspective]

### Context & Constraints
- [Geographic, technological, time-based, organizational constraints]

### Final Problem Statement
- [Single concise, empathetic summary for stakeholder alignment]

### Assumptions to Validate
- [Assumption 1]
- [Assumption 2]
```

**Next steps:** Generate testable solution hypotheses, convert into a workshop facilitation guide, or create stakeholder-specific variants (Exec, Eng, Design).

### Technique B: Working Backwards Press Release

Write an Amazon-style "future press release" announcing the product as if it already shipped. This forces you to articulate customer value before implementation.

```markdown
## Working Backwards Press Release

"[Product Name] by [Company] Aims to [Main Purpose/Goal]"

"[City], [Date] --"

"Today, [Company], a [type of organization], announced [product/feature],
a [brief description]. This [product] is set to [main benefit], addressing
[key issue or need]."

"[Product] will [what it does/solves]. [Quote from key person]:
'[customer-outcome-focused quote].' This initiative reflects [Company]'s
commitment to [core value]."

"In addition to [mentioned features], [product] also [additional benefits].
According to [source], [relevant data supporting the news]."

**Media Contact:** [Name, Title, Email]
```

**Writing rules:**
- Focus on customer outcomes, not feature lists.
- Avoid hype; favor credible claims and concrete benefits.
- If you can't write a compelling PR, the product concept needs more work.

**Next steps:** Generate an FAQ, create stakeholder-specific variants, generate objection-handling talking points, or define launch success metrics.

---

## PRD Framework (8 Sections)

### Section 1: Summary

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.

### Section 2: Contacts

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.

### Section 3: Background

Answer three questions:

1. **Context** -- What is the current state? What exists today?
2. **Why now?** -- What changed in the market, technology, or business that makes this urgent?
3. **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.

### Section 4: Objective

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]

### Section 5: Market Segment(s)

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"

### Section 6: Value Proposition(s)

For each market segment, define:

1. **Jobs addressed** -- What tasks or goals does this product help accomplish?
2. **Gains created** -- What positive outcomes does the user experience?
3. **Pains relieved** -- What frustrations, risks, or obstacles are removed?
4. **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.

### Section 7: Solution

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.

### Section 8: Release

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

## Writing Principles

- **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`

## Workflow

1. Gather context: product name, target segment, core problem.
2. Run `scripts/prd_scaffolder.py` to generate the skeleton.
3. Fill in each section using the guidance above and `references/prd-writing-guide.md`.
4. Review against the checklist in `references/prd-writing-guide.md`.
5. Share with stakeholders for feedback.

## Tools

| 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"` |

## Troubleshooting

| Symptom | Likely Cause | Resolution |
|---------|-------------|------------|
| PRD scaffolder output is too generic | Only product name provided; objective and segments need specificity | Write a 1-2 sentence objective that states the outcome, not just the product category; define segments by jobs-to-be-done, not demographics |
| Stakeholders skip reading the PRD | Document too long, too jargon-heavy, or lacks a clear Summary section | Ensure Section 1 (Summary) answers What/Who/Why in 3 sentences; cut any section beyond 1 page that is not Section 7 |
| Engineering team builds the wrong thing | PRD focuses on solution before establishing problem context | Strengthen Section 3 (Background) and Section 5 (Market Segments); ensure problem definition precedes solution |
| PRD assumptions never validated | Assumptions listed in Section 7 but no validation plan assigned | Add a validation plan column to the Assumptions table; link each assumption to `identify-assumptions/` or `brainstorm-experiments/` |
| Scope creep after PRD approval | Section 8 (Release) does not clearly separate v1 from future versions | Be explicit about "Explicitly Deferred" items; ensure every stakeholder has seen and acknowledged the deferred list |
| PRD becomes stale during development | Treated as a static document rather than a living reference | Update after implementation decisions change; archive final state and link to retrospective notes |
| `--segments` flag parsing fails | Segments not properly comma-separated or contain special characters | Wrap the segments argument in quotes: `--segments "Segment A, Segment B"` |

## Success Criteria

- PRD passes the "10-second executive test" -- a busy executive understands scope from Section 1 alone
- All 8 sections are complete before development begins (no placeholder sections remain)
- Market segments defined by jobs-to-be-done, not demographics
- Key Results in Section 4 are measurable with baselines, targets, and deadlines
- Every assumption in Section 7 has a validation plan and owner
- PRD reviewed by PM, Engineering Lead, Design Lead, and at least one stakeholder before commitment
- v1 scope in Section 8 draws a clear line between what ships and what is explicitly deferred

## Scope & Limitations

**In Scope:**
- 8-section PRD skeleton generation with guided placeholders
- Section-by-section writing guidance following plain-language, specificity-over-abstraction principles
- Market segment definition using jobs-to-be-done framework
- Value proposition mapping with Value Curve competitive analysis
- Release planning with Now/Next/Later and explicit deferral documentation

**Out of Scope:**
- Technical architecture or system design documents (see `engineering/` skills)
- User story writing and backlog creation (see `execution/job-stories/` and `execution/wwas/`)
- Detailed UX research or usability testing plans (see `product-team/` skills)
- Financial business case modeling (see `finance/` domain skills)

**Important Caveats:**
- A PRD is a communication tool, not a contract. Treat it as a living document that evolves with implementation learning.
- The 8-section framework is a proven structure, but lightweight agile teams may need only sections 1, 3, 4, 7, and 8. Heavyweight compliance contexts (medical devices, regulated industries) may need additional sections.
- A 2025 Carnegie Mellon SEI study found that effective requirements management eliminates 50-80% of project defects. The investment in a clear PRD pays for itself in reduced rework.

## Integration Points

| Integration | Direction | Description |
|------------|-----------|-------------|
| `discovery/identify-assumptions/` | Receives from | Validated and "Test Now" assumptions populate PRD Section 7 with evidence |
| `discovery/brainstorm-experiments/` | Receives from | Experiment results validate or invalidate PRD assumptions |
| `discovery/pre-mortem/` | Receives from | Tiger mitigations become PRD risk sections |
| `execution/brainstorm-okrs/` | Feeds into | PRD Key Results (Section 4) align with quarterly OKR targets |
| `execution/outcome-roadmap/` | Feeds into | PRD release plan (Section 8) maps to roadmap Now/Next/Later horizons |
| `execution/prioritization-frameworks/` | Receives from | Feature priority (P0/P1/P2) in Section 7 informed by RICE/ICE scoring |
| `senior-pm/` | Feeds into | PRD stakeholder context feeds stakeholder mapper engagement plans |

## Tool Reference

### prd_scaffolder.py

Generates a complete 8-section PRD markdown skeleton with guided placeholders, market segment sections, and value proposition templates.

| Flag | Type | Default | Description |
|------|------|---------|-------------|
| `--product-name` | string | (required) | Name of the product (used in title and headers) |
| `--objective` | string | (required) | Short description of the product objective (1-2 sentences) |
| `--segments` | string | (required) | Comma-separated list of market segments |
| `--output` | string | stdout | Output file path; if omitted, prints to stdout |

## References

- `references/prd-writing-guide.md` -- Section-by-section writing guide and review checklist
- `assets/prd_template.md` -- Complete PRD template ready to fill in

---

## What I Need You to Do

First, detect which platform I'm using (Claude.ai, ChatGPT, etc.) and follow the matching instructions below.

### If I'm on Claude.ai:

Walk me through these exact steps:

1. **Create the Project:** Tell me to go to **claude.ai > Projects > Create project** and name it **"Create Prd"**

2. **Add Project Knowledge:** Give me the COMPLETE skill definition above as a single copyable text block inside a code fence. Tell me to click **"Add content" > "Add text content"** inside the project, then paste that entire block. Do NOT say "paste from above" -- give me the actual text to copy right there.

3. **Set Custom Instructions:** Tell me to open project settings and paste this exact instruction:
   "You are an expert Create Prd in the Project Management domain. Use the project knowledge as your expertise. Follow the workflows, frameworks, and templates defined there. Always provide specific, actionable output."

4. **Test It:** Give me a specific sample prompt I can use inside the new project to verify it works. Pick a real task from the skill's workflows.

### If I'm on ChatGPT:

Walk me through these exact steps:

1. **Create a Custom GPT:** Tell me to go to **chatgpt.com > Explore GPTs > Create**
2. **Configure it:**
   - Name: **"Create Prd"**
   - Description: "PRD scaffolding expert that generates structured product requirements documents using an 8-section framework."
   - Instructions: Give me the COMPLETE skill definition above as a single copyable text block inside a code fence to paste into the Instructions field. Do NOT say "paste from above."
3. **Test It:** Give me a sample prompt to verify it works.

### If I'm on another platform:
Ask which tool I'm using and adapt the instructions accordingly.

## Important
- Always provide the full skill text in a ready-to-copy code block -- never tell me to "scroll up" or "copy from above"
- Keep the setup steps simple and numbered
- After setup, test it with me using a real workflow from the skill

Source: https://github.com/borghei/Claude-Skills/tree/main/project-management/execution/create-prd/SKILL.md