workflowPlanning & Scoping3 min read

Spec-Driven Development

Our take

The mature answer to vibe coding. Write a spec, let agents execute. This is how senior teams use AI in 2026.

GitHub's open-source toolkit for spec-driven development (SDD). Agents run a structured pipeline: constitution, spec, plan, tasks and implementation instead of one-shotting features from a paragraph prompt.

On this page8 parts

01The Problem
02What Spec Kit Gives You
03How to Run It
04Why This Matters for Senior Teams
05Where It Fits in the Stack
06When Not to Use It
07Source
08See It In Action

The Problem

Most AI-assisted work fails the same way: a vague prompt produces a plausible-looking implementation that misses half the requirements, gets the architecture wrong, or quietly contradicts something you shipped last month. You spend more time correcting the agent than you saved.

Spec-driven development flips the sequence. The spec becomes the source of truth, and code becomes a generated artifact against it. Agents stop guessing because you never asked them to guess.

What Spec Kit Gives You

A single CLI (specify) that installs slash commands into your coding agent — Claude Code, Copilot, Cursor, Gemini CLI, and 25+ others. Once installed, you run the workflow as commands inside your IDE. Each command produces a markdown artifact that the next command reads, so your agent always operates against a written, reviewable spec rather than conversational memory.

The workflow has six phases, each backed by a command:

/speckit.constitution - Project-level principles the agent must respect across every feature (testing policy, architectural guardrails, code review rules).
/speckit.specify - The "what and why." User stories, acceptance criteria, edge cases. No tech stack decisions yet.
/speckit.clarify - Structured Q&A to surface underspecified areas before they become rework.
/speckit.plan - The "how." Tech stack, data model, API contracts, file structure.
/speckit.tasks - Dependency-ordered task list the implementation phase walks through.
/speckit.implement - Executes tasks one by one, checking off the list as it goes.
/speckit.analyze - Cross-artifact consistency check - catches drift between spec, plan, and code.

How to Run It

Install the CLI and initialize Spec Kit in your repo. The --ai flag wires the commands into your agent of choice:

bash

1# Install once (requires uv — https://docs.astral.sh/uv)
2uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
3
4# Initialize in a new or existing project
5specify init --ai claude     # or copilot, cursor, gemini, etc.

Then the workflow inside your agent looks like this:

text

1/speckit.constitution  Establish: TypeScript strict, Vitest, no any, Conventional Commits.
2/speckit.specify       Add a contact-form rate limiter. 5 req/min per IP, surface a friendly error.
3/speckit.clarify       (Agent asks questions — you answer in plain English.)
4/speckit.plan          Use the existing Upstash Redis client. Middleware on /api/contact.
5/speckit.tasks         (Agent generates a dependency-ordered task list.)
6/speckit.implement     (Agent executes the tasks, one by one.)

Every phase writes a markdown file into specs/<feature>/. You review and edit those files like any other source artifact. They're part of the PR.

Why This Matters for Senior Teams

Review surface shifts to the spec.A 200-line diff is hard to audit. A 40-line spec is easy. Catch the design problem before 200 lines exist.
Works across agents.Your team can standardize the process even if individual engineers prefer different IDEs or models. The artifacts are portable markdown.
Pairs with parallel agents.Each feature has its own specs/ folder — drop it into a worktree, assign an agent, move on. No context collisions.
Turns AI output into reviewable work."The agent did it" becomes "here is the spec, the plan, the task list, and the diff — all in the PR."

Where It Fits in the Stack

Spec Kit is the planning layer. Combine with:

Worktree tooling(Superset, Vibe Kanban) to run multiple specs in parallel.
Review skills(sentry-code-review, ai-tools, Greptile) to audit the generated implementation against the spec.
Debugging skills(systematic-debugging) when the agent deviates — cheaper to root-cause a spec mismatch than a code mismatch.

When Not to Use It

Not every change needs a spec. One-line fixes, config tweaks, dependency bumps. Just ship them. Spec-driven flow earns its overhead on features with more than one moving part or a non-obvious acceptance criterion. Skip it for trivia; lean on it for anything you'd want to code-review in detail.

Source

Source on GitHubgithub.com (opens in a new tab)