interview-to-spec

Name: interview-to-spec
Author: eduwxyz

15stars1forks

How to install interview-to-spec?

eduwxyz/my-awesome-skills/interview-to-spec

$npx -y skills add eduwxyz/my-awesome-skills --skill interview-to-spec

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	Ask one question at a time.
4
5	If a question can be answered by exploring the codebase, explore it instead.
6
7	## One spec = one feature
8
9	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.
10
11	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.
12
13	When the user wants to do another one later, they invoke `interview-to-spec` again with that idea as the input.
14
15	## Writing the spec
16
17	When the interview converges, write the spec to `spec/<short-task-slug>.md` (create the directory if missing). Use these sections:
18
19	- Goal — what this task delivers, in user-facing language.
20	- Behaviors — what the system will do, observable from the outside.
21	- Acceptance criteria — how we know the work is done.
22	- Out of scope — what's deliberately not included.
23	- Edge cases — situations that need special handling.
24
25	Keep the spec focused on the what and why. Implementation details belong in a later step.

People who liked this also viewed

6 picks

Type

interview-to-spec

15stars1forks

View on GitHub

How to install interview-to-spec?

eduwxyz/my-awesome-skills/interview-to-spec

$npx -y skills add eduwxyz/my-awesome-skills --skill interview-to-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	Ask one question at a time.
4
5	If a question can be answered by exploring the codebase, explore it instead.
6
7	## One spec = one feature
8
9	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.
10
11	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.
12
13	When the user wants to do another one later, they invoke `interview-to-spec` again with that idea as the input.
14
15	## Writing the spec
16
17	When the interview converges, write the spec to `spec/<short-task-slug>.md` (create the directory if missing). Use these sections:
18
19	- Goal — what this task delivers, in user-facing language.
20	- Behaviors — what the system will do, observable from the outside.
21	- Acceptance criteria — how we know the work is done.
22	- Out of scope — what's deliberately not included.
23	- Edge cases — situations that need special handling.
24
25	Keep the spec focused on the what and why. Implementation details belong in a later step.

People who liked this also viewed

6 picks

Type