v1.0

2026-03-02 00:36:23 +01:00
parent 61004d0c4e
commit 77dbdfa1b9
118 changed files with 11087 additions and 0 deletions
@@ -0,0 +1,118 @@
+---
+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