Interview to spec
Claude Code plugin marketplace shipping an SDD pipeline (interview-to-spec, diagnose, spec-approach, tdd, verify) with hooks that turn skill rules into mechanical guarantees.
npx -y skills add eduwxyz/my-awesome-skills --skill interview-to-specAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
2.3 KB, as published. Nobody here has run it
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.