Chapter 2 · Spec-Driven Development in Depth · Lesson 2.2

Spec Kit, End to End

Walk GitHub Spec Kit's full loop once - from installing the CLI to generated code - so the whole workflow becomes concrete instead of abstract.

What Spec Kit is, in one line

Spec Kit is GitHub's open-source, MIT-licensed toolkit for spec-driven development - agent-neutral, and driven by a command-line tool called specify (GitHub Spec Kit). You install one CLI; it drops a set of slash commands into whatever coding agent you already use, and those commands run the spec-first workflow for you.

The rest of this lesson walks the loop once, start to finish. By the end you should be able to install Spec Kit and run its constitution → specify → plan → tasks → implement sequence yourself.

Install it

Two commands. The first installs the CLI; the second scaffolds a project and wires the slash commands into your agent (Spec Kit docs):

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

specify init my-project --integration claude

One gotcha worth knowing up front: as of v0.10 the flag is --integration. It replaced the older --ai flag, so older tutorials and blog posts may show --ai claude, which no longer works. If a command fails, check the flag name first (Spec Kit docs). Swap claude for whatever agent you run - Spec Kit supports many.

The constitution comes first

Before any feature work, you write a constitution: a one-time document of your project's non-negotiable principles - things like "always write tests", "never break the public API", "prefer boring, well-understood tech". You run this once per project, and every later command references it (GitHub Spec Kit). Think of it as the permanent rulebook that sits above every individual spec.

The loop, command by command

Once the constitution exists, each slash command produces one artifact and hands it to the next command. Here is the full sequence and what each step writes:

/speckit.constitution  ->  project principles (run once)
/speckit.specify       ->  spec.md    (the WHAT and WHY, no tech detail)
/speckit.clarify       ->  fills in ambiguity left in the spec
/speckit.plan          ->  plan.md    (the technical approach)
/speckit.tasks         ->  tasks.md   (an ordered task list)
/speckit.implement     ->  the code, one task at a time

Walk it slowly. /speckit.specify captures what you want and why, deliberately holding off on any technology choices. /speckit.clarify then interrogates that spec and fills the gaps you left, so the agent is not guessing later. /speckit.plan is where the how finally arrives - the technical approach. /speckit.tasks breaks the plan into an ordered checklist. Only then does /speckit.implement write code, task by task (Spec Kit docs).

The point that makes this work is the artifact chain: spec.md → plan.md → tasks.md → code. Each phase feeds the next, and each is reviewed before you advance. You read the spec before planning; you read the plan before breaking it into tasks; you read the tasks before code gets written. Nothing skips ahead on a guess.

The spec is the source of truth; the code is generated to serve it - not the other way around. GitHub Spec Kit

Why the chain matters

These are not just files for your benefit. Each artifact is real context the agent reads on the next step - structured intent instead of an ad-hoc prompt typed in a hurry. And because spec.md, plan.md, and tasks.md are committed to the repo, they are reviewable and durable: they survive a new session, a context reset, and a teammate's clone. That makes them part of your harness, not throwaway chat. When something goes wrong, you fix the spec once and every future run inherits the fix - the same tightening loop the ratchet is built on.

The Spec Kit loop

Check yourself

Spec Kit's workflow is driven by -

Spec Kit is an agent-neutral toolkit driven by the specify command-line tool, which drops slash commands into the agent you already use - no dashboard, model, or paid service involved.

The constitution command is run -

The constitution is a one-time document of a project's non-negotiable principles. You write it once per project, and every later command references it - it does not replace the per-feature specs.

In Spec Kit the code is -

The spec is the source of truth; code is the generated output that serves it. That reversal - spec first, code second - is the whole point of the spec.md → plan.md → tasks.md → code chain.

Do this now (15 min)

On a throwaway project, run the front of the loop end to end:

Then open the generated spec.md and read it. Notice that it captured the WHAT and WHY before a single line of code existed. That is the whole shift, made concrete.

I'm your teacher - ask freely. Want me to walk you through your first specify init live - picking the right --integration, writing a first constitution, or reading your generated spec.md together? Say the word and we'll do it step by step.

Go deeper

Primary source (start here): the GitHub Spec Kit repo and its documentation. The README and docs are the canonical reference for every command and flag - check them first when a tutorial's commands look outdated.

Wisdom (test it on people): r/ChatGPTCoding - active, practical debate on how the Spec Kit loop holds up on real projects.

← 2.1 The SDD mindset & the trio Course map Glossary Next: 2.3 Spec Kit in practice →