write-prdlisted

# Write PRD Produce `docs/specs/<feature-slug>/_prd.md` — the product definition the rest of the pipeline (`write-techspec`, `write-tasks`, `implement-task`, `qa-gate`) implements from. The PRD owns _what_ and _why_; the tech spec owns _how_. Keeping that boundary is what lets each artifact stay small and stay true while the code changes underneath it. ## Inputs `$ARGUMENTS` is a feature description, or empty when the current conversation already explored the feature (a grilling or brainstorm session). Everything already answered in the conversation counts as answered — do not re-interview. If `docs/specs/<slug>/_idea.md` exists (produced by `write-idea`), it **is** the exploration: read it first, and treat its research, scoring, council insights, chosen direction, and Out of Scope list as answered ground truth. Clarify only what the idea left open. ## Size triage first Not every change earns a PRD — it pays for itself when there are product decisions to record and multiple tasks to derive. If the work changes no product behavior (a refactor, a bug fix), say so and route to `write-techspec`, which enters the pipeline directly and mints the spec folder with a minimal `_prd.md`. If the change is trivial (one-line fix, typo, config tweak), recommend direct implementation with no spec folder. ## Ground rules - **Read `CONTEXT.md` and `docs/adr/` before anything else.** Use the glossary's vocabulary throughout — titles, user stories, feature names — and never drift to syno