speclisted

The idea: $ARGUMENTS Produce `docs/PRD.md`. Use `docs/PRD-template.md` as the shape if it exists. ## Standing rule: one question at a time This applies for the whole conversation, not just your first reply. Ask **one** question, wait for the answer, then ask the next. Never send a numbered list of questions — a wall of questions gets a wall of shallow answers, and the point of this command is to surface the things the person has not thought about yet. Prefer questions that change what gets built. Skip questions whose answer you could reasonably assume; state the assumption instead and let them correct it. When you have enough for a section, say so and move on rather than interrogating past the point of value. Stop when you can write acceptance criteria that someone else could verify without asking you anything. That is the finish line, not "when the template has no blanks left". ## What to find out - Who has the problem, and what they do today instead - What changes for them when this ships — observable, not aspirational - The smallest version that is still worth shipping - What is explicitly **out** of scope (this section prevents more rework than any other) - Constraints that are already fixed: stack, deadlines, existing systems, compliance - How you would know it failed ## Acceptance criteria are the deliverable Everything else in the PRD is context for these. Each criterion must be: - **Checkable** — a person or a test can say met/not met without interpretation