Skill
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"), interview them one question at…
@eduwxyzView 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
Install
$ npx -y skills add eduwxyz/my-awesome-skills --skill interview-to-spec --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/interview-to-spec
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
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.
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.
Get the whole plugin
Other skills on sdd-pipeline.
@eduwxyzView SkillSkill
feature
Kick off the full feature workflow — interview-to-spec, optional spec-approach, tdd, verify, then review — when starting a new feature from scratch. Thin…
@eduwxyzView SkillSkill
spec-approach
Add a refined `## Approach` section to an existing feature spec.md before TDD executes it. Reads the spec, explores the codebase to ground the approach in real…
@eduwxyzView SkillSkill
tdd
Drives feature work and bug fixes through a tight failing-test-first loop. Trigger when implementing, fixing, or refactoring behavior in a codebase that…
@eduwxyzView Skill