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>
4.9 KiB
name, description
| name | description |
|---|---|
| prd | 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".
- Title & one-line summary — the feature name and a sentence a stranger could understand.
- Problem — what's broken or missing today, who it hurts, evidence it matters. No solution talk yet.
- Goals — 2–5 bullets, each a concrete outcome (not an activity). "Reduce X by Y" beats "improve X".
- 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.
- 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.
- 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.
- Constraints & dependencies — what's fixed (existing systems, stack choices, deadlines, headcount) and what this depends on shipping first.
- 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.
- Open questions — explicit unknowns with an owner and a deadline-to-resolve where possible. This is where grilling gaps land.
- 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.