If you read one line: uv tool install specify-cli --from git+https://github.com/github/spec-kit.git, then specify init my-project --integration claude, then drive the build inside your agent with /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement. Each step writes a Markdown file you review before the next one runs.

If you've read our vibe coding vs spec-driven development decision guide and decided a particular feature deserves the spec treatment, this is how you actually do it — with the free, open-source tool that made the workflow concrete. GitHub Spec Kit is a small CLI plus a set of slash commands that turn "build me a feature" into a reviewable pipeline of artifacts. Nothing here locks you into a platform: it's MIT-licensed, and it runs inside whichever coding agent you already use.

Step 1 — Install the specify CLI#

Spec Kit is distributed as a Python command-line tool named specify. The recommended installer is uv, Astral's fast Python package manager, though pipx also works. You need Python 3.11 or newer, Git, and uv on your PATH before you start — on macOS or Linux, curl -LsSf https://astral.sh/uv/install.sh | sh gets you uv if you don't have it. Installing the CLI globally means every project on your machine can scaffold a spec-driven workflow without re-downloading anything.

# Install the Spec Kit CLI globally with uv
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# Confirm it's on your PATH
specify --help

Step 2 — Initialize a project and pick your agent#

With the CLI installed, you scaffold a project with specify init. This is where you tell Spec Kit which coding agent you're driving — it writes the slash-command definitions into the format that agent expects, so the same workflow works whether you're in Claude Code, Copilot, or Cursor. As of the v0.11 line it supports 30-plus agents; pass your choice with --integration. Run this once per project, at the repo root you want the spec artifacts to live in.

# Scaffold a new project wired to Claude Code
specify init my-feature --integration claude

# ...or Copilot, Cursor, Gemini CLI, Codex CLI, Windsurf, Goose, etc.
specify init my-feature --integration copilot

cd my-feature

The init creates a .specify/ directory holding the command templates and a place for the artifacts you're about to generate. From here on, you work inside your agent, not the shell.

Step 3 — Set the constitution (optional, but do it once)#

Before you describe any feature, it's worth spending five minutes on the project's non-negotiables. The /speckit.constitution command captures the governing principles the agent must respect across every future spec — your testing standards, your architectural constraints, "never store secrets in the repo," "all endpoints require auth." These get written to constitution.md and injected into later steps, so a rule you state once is honored on every feature you generate afterward. Skip it for a one-off; set it for anything you'll build on repeatedly.

/speckit.constitution Establish principles: TypeScript strict mode, all HTTP
handlers validate input with zod, no secrets in source, every feature ships
with tests. Prefer boring, well-documented libraries over clever ones.

Step 4 — Specify what to build, then clarify#

Now describe the feature — the what, not the how. The /speckit.specify command takes your natural-language description and expands it into a structured spec.md: requirements, user stories, and acceptance criteria. Resist the urge to name frameworks here; that's the plan's job. Once the spec exists, run /speckit.clarify — it interrogates the spec for under-specified areas and asks you the questions you glossed over. This is the single highest-leverage step, because an assumption caught here is a bug that never reaches the code.

/speckit.specify Build a waitlist feature: visitors submit an email on a landing
page, receive a confirmation, and land on a "you're #N in line" page. Admins can
export the list as CSV. Duplicate emails are idempotent, not errors.

/speckit.clarify

Read the resulting spec.md and answer the clarifying questions before moving on. This is a review gate, not a formality — the spec is now the source of truth, so it's worth getting right while it's still cheap to change.

Step 5 — Plan the tech stack, then break it into tasks#

With an agreed spec, /speckit.plan is where architecture enters. Here you tell the agent your stack and constraints, and it produces plan.md: the technical approach, the data model, the components, how the pieces fit. Because the plan is derived from the spec rather than invented alongside the code, it stays honest about what the feature actually needs. Then /speckit.tasks decomposes that plan into tasks.md — an ordered, actionable checklist an agent can execute one item at a time.

/speckit.plan Use Next.js 15 app router, a Postgres table via Drizzle ORM, and
Resend for the confirmation email. Store the waitlist position as a computed
count, not a stored column. Rate-limit submissions by IP.

/speckit.tasks

Optionally run /speckit.analyze here — it cross-checks the spec, plan, and tasks for consistency and coverage, catching the case where a requirement in spec.md never became a task. On anything with more than a handful of tasks, it's worth the extra minute.

Step 6 — Implement, and review the diff#

The final step, /speckit.implement, executes the task list and writes the actual code against the plan. Because everything upstream is written down, this stage is far more predictable than a cold "build me this" prompt — the agent is filling in a plan it already agreed to, not improvising the whole design at generation time. Treat the output the way you'd treat a colleague's pull request: read the diff, run the tests, and if something's off, fix it at the spec or plan level and regenerate rather than hand-patching the code.

/speckit.implement

That last habit is the whole point of spec-driven development. When the waitlist needs a referral field next quarter, you don't re-explain the feature to an agent that's forgotten it — you edit spec.md, regenerate the affected slice, and review the diff. The intent lives in a versioned file, not a lost chat. If you're weighing whether a given piece of work is worth this ceremony at all, that's exactly the call our vibe-vs-spec decision guide is built to help you make — and once you've shipped, our maintenance and security checklist picks up where the spec leaves off.