to-prdlisted

# to-prd Synthesize the current conversation into a **PRD** and publish it as a single planning **document** on the tracker. The PRD is the front of the pipeline: it is **not** a wave slice — it carries no wave Header-Block and is never eligibility-stamped, so it never enters a wave. The downstream `to-issues` skill later slices it into independently-grabbable, wave-eligible issues, each backlinked to it via `Parent`. Your job is the **judgment** — synthesizing what the conversation already established into a tight, structured PRD and confirming its scope. The engine is the guardrail: it publishes through the store's Document facet, assigns the id, and renders the body. So this skill stays on the judgment; the CLI invocation detail (commands, JSON shape, verify) lives in [reference/filing-mechanics.md](reference/filing-mechanics.md) — reach for it once the draft is confirmed. You never write a tracker directly; everything goes through the engine CLI (`{{wave-cli}}`). Do **not** interview the user from scratch — synthesize what you already know. Do confirm the drafted structure before publishing. ## When to Use - A design discussion, spec, or brainstorm in the conversation is ready to be captured as a PRD. - The user says "write a PRD", "turn this into a PRD", "draft requirements". - An upstream skill (e.g. `brainstorming`, `grill-with-docs`) has settled a design and hands off the writeup. Do **not** use this to slice work into tickets — that is `to-issues`. Do not triag