mirror of
https://github.com/phuryn/pm-skills.git
synced 2026-06-11 22:14:56 +03:00
Pawel Huryn
119 lines
3.9 KiB
Markdown
119 lines
3.9 KiB
Markdown
---
|
|
description: Create a comprehensive Product Requirements Document from a feature idea or problem statement
|
|
argument-hint: "<feature or problem statement>"
|
|
---
|
|
|
|
# /write-prd -- Product Requirements Document
|
|
|
|
Create a structured PRD that aligns stakeholders and guides development. Accepts anything from a vague idea to a detailed brief.
|
|
|
|
## Invocation
|
|
|
|
```
|
|
/write-prd SSO support for enterprise customers
|
|
/write-prd Users are dropping off during onboarding — we need to fix step 3
|
|
/write-prd [upload a brief, research doc, or strategy deck]
|
|
```
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Understand the Feature
|
|
|
|
Accept the input in any form:
|
|
- A feature name ("SSO support")
|
|
- A problem statement ("Enterprise customers keep asking for centralized auth")
|
|
- A user request ("Users want to export their data as CSV")
|
|
- A vague idea ("We should do something about onboarding drop-off")
|
|
- An uploaded document (brief, research, Slack thread, email)
|
|
|
|
### Step 2: Gather Context
|
|
|
|
Ask conversationally — most important questions first, fill gaps as you go:
|
|
|
|
1. **User problem**: What problem does this solve? Who experiences it? How painful is it?
|
|
2. **Target users**: Which user segment(s)? How many? What's their current workaround?
|
|
3. **Success metrics**: How will we know this worked? What moves if we nail it?
|
|
4. **Constraints**: Technical constraints, timeline, regulatory, dependencies on other teams?
|
|
5. **Prior art**: Has this been attempted before? Existing solutions in the market?
|
|
6. **Scope preference**: Full solution or phased approach?
|
|
|
|
If the user provides a document with context, extract what's available and only ask about gaps.
|
|
|
|
### Step 3: Generate the PRD
|
|
|
|
Apply the **create-prd** skill to produce an 8-section document:
|
|
|
|
```
|
|
## Product Requirements Document: [Feature Name]
|
|
|
|
**Author**: [user]
|
|
**Date**: [today]
|
|
**Status**: Draft
|
|
**Stakeholders**: [if known]
|
|
|
|
### 1. Executive Summary
|
|
[2-3 sentences: what, for whom, why now]
|
|
|
|
### 2. Background & Context
|
|
[Problem space, prior research, market context, what prompted this]
|
|
|
|
### 3. Objectives & Success Metrics
|
|
**Goals** (what success looks like):
|
|
1. [Specific, measurable goal]
|
|
2. [...]
|
|
|
|
**Non-Goals** (explicitly out of scope):
|
|
1. [What we're not doing, and why]
|
|
2. [...]
|
|
|
|
**Success Metrics**:
|
|
| Metric | Current | Target | Measurement |
|
|
|--------|---------|--------|-------------|
|
|
|
|
### 4. Target Users & Segments
|
|
[Who this serves, user profiles, segment sizing]
|
|
|
|
### 5. User Stories & Requirements
|
|
|
|
**P0 — Must Have**:
|
|
| # | User Story | Acceptance Criteria |
|
|
|---|-----------|-------------------|
|
|
|
|
**P1 — Should Have**:
|
|
| # | User Story | Acceptance Criteria |
|
|
|---|-----------|-------------------|
|
|
|
|
**P2 — Nice to Have / Future**:
|
|
| # | User Story | Acceptance Criteria |
|
|
|---|-----------|-------------------|
|
|
|
|
### 6. Solution Overview
|
|
[High-level approach, key design decisions, technical approach if known]
|
|
|
|
### 7. Open Questions
|
|
| Question | Owner | Deadline |
|
|
|----------|-------|----------|
|
|
|
|
### 8. Timeline & Phasing
|
|
[Milestones, dependencies, phasing if applicable]
|
|
```
|
|
|
|
### Step 4: Review and Iterate
|
|
|
|
After generating, offer:
|
|
- "Want me to **tighten the scope**? I can challenge which P1s should really be P2s."
|
|
- "Should I **run a pre-mortem** on this PRD?"
|
|
- "Want me to **break this into user stories** for engineering?"
|
|
- "Should I **create a stakeholder update** to socialize this?"
|
|
|
|
Save the PRD as a markdown file to the user's workspace.
|
|
|
|
## Notes
|
|
|
|
- Be opinionated about scope — a tight PRD is better than an expansive vague one
|
|
- If the idea is too big, proactively suggest phasing and spec only Phase 1
|
|
- Non-goals are as important as goals — they prevent scope creep
|
|
- Success metrics must be specific: "improve NPS" is bad, "increase NPS from 32 to 45 within 90 days of launch" is good
|
|
- Open questions should be genuinely unresolved — don't list things you can answer from context
|
|
- If the user provides research, weave insights into the Background section with attribution
|