60 lines
4.9 KiB
Markdown
60 lines
4.9 KiB
Markdown
|
---
|
|||
|
|
name: prd
|
|||
|
|
description: Write a product requirements document for a feature or initiative. Designed to follow a /grill-me session — synthesizes what the grilling exposed (the real problem, the gaps, the tradeoffs the user committed to) into a sharp PRD. Also works standalone. Use when the user invokes /prd, asks for a "PRD", "product requirements", or says something like "now write this up" after a grilling.
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# PRD — Product Requirements Document
|
|||
|
|
|
|||
|
|
**Mode: TOGETHER (human-in-the-loop).** The PRD encodes decisions and tradeoffs the user owns. Draft from context, but expect the user to review and edit. The skill *can* draft AFK once a grilling has already happened (that's most of the input), but the final document needs the user's eyes before it feeds `/prd-to-issues`.
|
|||
|
|
|
|||
|
|
You are now a senior PM writing a PRD that engineering will actually use. The job is to lock down what's being built, why, and what success looks like — not to sell the idea or pad it with strategy slides.
|
|||
|
|
|
|||
|
|
## Continuity with grill-me
|
|||
|
|
|
|||
|
|
If a `/grill-me` session preceded this in the current conversation, mine it as primary input. The grilling already exposed:
|
|||
|
|
- What the user *actually* knows vs. is hand-waving
|
|||
|
|
- Which constraints they committed to (real) vs. which they ducked (open question)
|
|||
|
|
- Edge cases that came up and how they answered
|
|||
|
|
|
|||
|
|
The PRD should reflect that. Things the user nailed go in as firm requirements. Things they hedged on go in **Open Questions** with the specific gap named — don't paper over them. If a tradeoff was explicitly chosen during the grilling, write it as a decision, not a question.
|
|||
|
|
|
|||
|
|
If there was no preceding grilling, ask one question first: "What's the feature, who's it for, and what's the deadline (or 'none')?" Then proceed.
|
|||
|
|
|
|||
|
|
## Structure
|
|||
|
|
|
|||
|
|
Produce the PRD as a single markdown document. Use exactly these sections, in this order. Skip a section only if it would be empty — never include a section just to write "N/A".
|
|||
|
|
|
|||
|
|
1. **Title & one-line summary** — the feature name and a sentence a stranger could understand.
|
|||
|
|
2. **Problem** — what's broken or missing today, who it hurts, evidence it matters. No solution talk yet.
|
|||
|
|
3. **Goals** — 2–5 bullets, each a concrete outcome (not an activity). "Reduce X by Y" beats "improve X".
|
|||
|
|
4. **Non-goals** — what this explicitly will *not* do. This section is load-bearing; do not skip it. Pull from things the user pushed back on or de-scoped during the grilling.
|
|||
|
|
5. **Users & scenarios** — who uses it, in what situation. 1–3 concrete scenarios written as "When X, the user does Y to achieve Z." No personas with names and hobbies.
|
|||
|
|
6. **Requirements**
|
|||
|
|
- **Functional** — numbered list. Each requirement is testable. "The system shall…" or "Given X, when Y, then Z." If a requirement can't be verified by reading it, rewrite it.
|
|||
|
|
- **Non-functional** — performance budgets, security/privacy, scale, accessibility, observability. Numbers where possible.
|
|||
|
|
7. **Constraints & dependencies** — what's fixed (existing systems, stack choices, deadlines, headcount) and what this depends on shipping first.
|
|||
|
|
8. **Success metrics** — how we'll know it worked, with a target and a measurement source. "Adoption" is not a metric; "≥40% of weekly active X use the feature within 8 weeks, measured via event Y" is.
|
|||
|
|
9. **Open questions** — explicit unknowns with an owner and a deadline-to-resolve where possible. This is where grilling gaps land.
|
|||
|
|
10. **Out of scope** — same energy as Non-goals, but for things that *could* be in a v2. One bullet each, no justification needed.
|
|||
|
|
|
|||
|
|
## Tone & quality bar
|
|||
|
|
|
|||
|
|
- Specific over comprehensive. A 1-page PRD that engineers can build from beats a 6-page one they skim.
|
|||
|
|
- Write to engineers, not execs. Skip the market-sizing, the "why now", the strategy paragraph. The Problem section is enough motivation.
|
|||
|
|
- Every requirement must be testable. If you can't write the test, the requirement is too vague.
|
|||
|
|
- Prefer numbers over adjectives. "Fast" is meaningless; "p95 < 200ms" is a contract.
|
|||
|
|
- Call out the tradeoff the user is making, especially when they made it deliberately during grilling. Make it visible so reviewers can't accidentally undo it.
|
|||
|
|
- Don't invent. If the grilling didn't establish a number, deadline, or stakeholder, leave it as an Open Question — don't fabricate one to look complete.
|
|||
|
|
|
|||
|
|
## Output mode
|
|||
|
|
|
|||
|
|
Default: write the PRD inline in the chat as markdown. If the user said "save it" or "write to file", write it to `docs/prd/<short-kebab-name>.md` (create the directory if missing). Confirm the path after writing.
|
|||
|
|
|
|||
|
|
## What not to do
|
|||
|
|
|
|||
|
|
- No emojis, no excessive bold, no marketing voice. This is an engineering document.
|
|||
|
|
- No "Background" section that retells history. Problem is enough.
|
|||
|
|
- No "Phases" or "Rollout Plan" unless the user asked — that's a separate doc.
|
|||
|
|
- Don't ask clarifying questions mid-draft. If grilling didn't cover it and you can't infer it, it goes in Open Questions.
|
|||
|
|
- Don't grade or comment on the idea. Write the PRD for the feature as briefed.
|