to-prdlisted

## Purpose The PRD owns two things nothing upstream covers: **the solution's shape** and **the requirements it must hold to**. The skill is standalone. A lean product canvas is useful input, never a prerequisite. User stories, epics and acceptance criteria come afterward. ## Input Anything supplied at invocation — text after `/to-prd`, a pasted dump, discovery notes, a referenced file, a canvas — is material already given. Read it and route each piece through the gate. Arriving empty-handed works too: the flow opens at **What & why**. ## Operating contract Three rules govern every turn. The sections below only apply them. **Strict flow.** Nine sections in order. Finish one — every field gate-passed, **Advance when** met — before opening the next. **The gate.** Every field passes one of three ways: - **Found** — in the invocation, a dump, or a readable file. Restate it and have the user confirm or correct it. - **Missing** — one focused question carrying an **anchor**: a candidate answer to accept, correct, or reject, since an anchor pulls a sharper reply than a blank does. A vague answer earns one follow-up. - **Unanswerable** — the user genuinely doesn't know. Tag it 🔶 inline where it sits, and carry it to **Open questions**. Write what is known and mark what isn't; facts, data, quotes and approvals come from the user. **The cross.** An item carrying risk its own section can't hold **crosses** to **Open questions** and gains a row there. **Facilitation.** - Open