diagnose
Turn a bug symptom into a fix with a regression test that locks it down. If the user opens vague ("there's a bug", "/diagnose"),…
@eduwxyzInstall SkillDevelopment
Skill
/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
Claude Code
$ npx -y skills add eduwxyz/my-awesome-skills --skill interview-to-spec --agent claude-code
Codex
$ npx skills add eduwxyz/my-awesome-skills --skill interview-to-spec -a codex -y
Cursor
$ npx skills add eduwxyz/my-awesome-skills --skill interview-to-spec -a cursor -y
Gemini CLI
$ npx skills add eduwxyz/my-awesome-skills --skill interview-to-spec -a gemini-cli -y
GitHub Copilot
$ npx skills add eduwxyz/my-awesome-skills --skill interview-to-spec -a github-copilot -y
OpenCode
$ npx skills add eduwxyz/my-awesome-skills --skill interview-to-spec -a opencode -y
Windsurf
$ npx skills add eduwxyz/my-awesome-skills --skill interview-to-spec -a windsurf -y
SKILL.md
interview-to-spec.SKILL.mdname: interview-to-spec
description: 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.
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.
Read more
name: interview-to-spec description: 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.
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.
Stats
15
Stars
1
Forks
Maintained
Maintenance
Shell
Language
Last commit
Created
Ships withsdd-pipeline
A spec-driven development pipeline for Claude Code and Codex CLI. Refine the spec before you code, let TDD enforce it, verify nothing slipped, then review.
166 skills
Stars on GitHub
Momentum
- stars in total
- 16
Other skills on sdd-pipeline.
@eduwxyzInstall Skillfeature
Kick off the full feature workflow — interview-to-spec, optional spec-approach, tdd, verify, then review — when starting a new…
@eduwxyzInstall Skillspec-approach
Add a refined `## Approach` section to an existing feature spec.md before TDD executes it. Reads the spec, explores the codebase…
@eduwxyzInstall Skilltdd
Drives feature work and bug fixes through a tight failing-test-first loop. Trigger when implementing, fixing, or refactoring…
@eduwxyzInstall SkillMore skills from other plugins.
Auto-invoked
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
@obraInstall Skillask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
@mattpocockInstall SkillAuto-invoked
Questions about interview-to-spec.
- Which coding agents can use interview-to-spec?
- interview-to-spec installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.