to-prd

To PRD

Turn the conversation and codebase into a short PRD a human actually reads, then publish it as a GitHub issue.

/to-prd [--title="..."] [--label=Plan] [--issue=N]

  1. Gather context (conversation + light repo read)
  2. Clarify gaps via AskUserQuestion   (gate, only if thin)
  3. Draft the PRD
  4. Show it, wait for approval          (gate)
  5. Publish the issue; print URL + number

Arguments

Arg	Default	Notes
--title="..."	Derived from context	Issue title
--label=...	Plan	Dropped if the repo has no such label; pass --label= for none
--issue=N	Create new	Re-publish: replace the PRD, keep any appended slices/PRs

Phase 1 — Gather context

Read the conversation; explore the repo only if you haven't. Use the codebase's own vocabulary and respect existing ADRs.

Phase 2 — Clarify (gate)

If a fact that changes the design is missing, ask with AskUserQuestion (≤4 at a time, concrete options) — otherwise skip when context is rich.

Phase 3 — Draft

Write it tight:

• One screen. Cut anything that doesn't change a decision.
• The english rule governs every line — it loads each session, so you already have it. Cut all hedging.
• Tables and bullets over paragraphs. A PRD is scanned, not read: this is the one document where a list beats prose.
• Only what was discussed or confirmed — invent nothing.
• No file paths or code; they rot. Rare exception: a tiny snippet that nails a decision — a type, a schema.

Use these sections:

## The problem
<What's wrong today, in the reader's words. One short paragraph.>

## What we're building
<A few sharp sentences. The core idea.>

## How it works
<The key mechanics as bullets.>

## Decisions already made
<Table: Area | Choice.>

## In scope / Out of scope
<Two short lists.>

## Open questions
<What still needs the user's call. Omit if none.>

Phase 4 — Approve (gate)

Show the draft in chat. Wait for an OK or edits. Don't publish until approved.