# Interview To Spec

> Conduct a focused interview to draft a spec.md for an upcoming task (the input step of SDD — spec-driven development). Walks through goal, behaviors, acceptance criteria, edge cases, and out-of-scope one branch at a time, then writes the spec to disk. If during the interview the scope turns out to be multiple independent features, pauses and asks the user to pick one — the chosen one becomes the spec, the rest stay outside the repo. Trigger when the user wants to draft a spec before implementation, mentions "draft the spec", "let's spec this out", "what should we build", or starts an SDD workflow.

- Skill: `eduwxyz/interview-to-spec` (Agent Skill)
- Install (CLI): `npx skillmds@latest add eduwxyz/interview-to-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eduwxyz/interview-to-spec/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: eduwxyz (https://skillmd.com/u/eduwxyz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/eduwxyz/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.