interview-to-spec

Interview the user to draft a spec for the task at hand. Cover goal, behaviors, acceptance criteria, edge cases, and out-of-scope — one branch at a time, resolving each before moving on. For every question, offer your own recommended answer.

Ask one question at a time.

If a question can be answered by exploring the codebase, explore it instead.

One spec = one feature

If during the interview you sense the scope is actually multiple independent features (separate goals, different code paths, would ship as separate PRs), pause and propose a split. Show 2–5 one-line options and ask the user to pick which one to spec first.

Continue the interview for only that one. The others stay outside the repo — the user manages them wherever they keep their backlog (issue tracker, notes, their head). Do not mention them in the spec. Do not add a "follow-up" or "future work" section. Do not create a roadmap file. The spec describes only the work being executed now.

When the user wants to do another one later, they invoke interview-to-spec again with that idea as the input.

Writing the spec

When the interview converges, write the spec to spec/<short-task-slug>.md (create the directory if missing). Use these sections:

• Goal — what this task delivers, in user-facing language.
• Behaviors — what the system will do, observable from the outside.
• Acceptance criteria — how we know the work is done.
• Out of scope — what's deliberately not included.
• Edge cases — situations that need special handling.

Keep the spec focused on the what and why. Implementation details belong in a later step.