6ff262e96e
Four workflow skills that take a feature from fuzzy idea to merged code.
Two human-in-the-loop phases (grill-me, prd), one mostly-together (prd-to-issues
files only on explicit 'create'), and one AFK (ship-it).
grill-me TOGETHER pressure-test the idea with hard interview questions
prd TOGETHER synthesize PRD; gaps stay explicit, not papered over
prd-to-issues MOSTLY thin vertical-slice issues with coverage matrix +
per-issue Slice check; self-audits before showing
ship-it AFK shell loop ships each slice end-to-end with one
commit per issue, status streams to terminal,
Ctrl-C-able, survives session close
Vertical-slice principle throughout: every issue cuts end-to-end through every
integration layer (no horizontal "do all the DB work first" issues). The
AFK loop only ships against acceptance criteria already locked in by the PRD
phase — autonomous code never runs against undefined contracts.
ship-it tracker support: gh (GitHub) and tea (Gitea). For this repo, set
SHIP_IT_TRUNK=development to override the main default.
See .claude/skills/README.md for the full how-to and a worked example.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
|