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.