Spec Kit: a spec-driven workflow for AI coding agents

The problem Spec Kit targets: agents that start coding too early

The README frames the project against what it calls traditional software development, where specifications were scaffolding discarded once coding began. Its claim is that specifications become executable, directly generating working implementations rather than guiding them. That is the pitch, and it is worth separating from what the tool does mechanically.

What the toolkit actually ships is a process. You install a CLI, it scaffolds a project with templates and slash commands, and those commands walk a coding agent through constitution, specify, plan, tasks, implement and converge. The audience is teams already using an agent such as Copilot, Claude Code or Cursor on work that spans more than a single prompt, where the failure mode is an agent that produces plausible code for the wrong requirement. Spec Kit's answer is to make the requirement a file in the repository before any implementation exists.

The project reached 1.0.0 in August 2026, one year after its first commit. The release note in the README is unusually candid about what that version number means: the lead maintainer's anniversary post says 1.0.0 is now just a number, and that as agents make adapting to change cheaper, the value moves from stability to adaptability. Read that as a signal about API and template churn rather than as a stability guarantee.

How the Specify CLI, templates and slash commands fit together

Three pieces do the work. The first is the specify CLI, a Python package named specify-cli that requires Python 3.11 or newer and is built with hatchling. Its dependencies are typer, click, rich, platformdirs, readchar, pyyaml, packaging, pathspec and json5. The entry point is specify, mapped to specify_cli:main.

The second piece is the core pack. The pyproject.toml force-includes templates, command definitions and scripts into the wheel, with a comment stating the goal is that specify init works without network access in air-gapped or enterprise settings. Page templates include constitution-template.md, spec-template.md, plan-template.md, tasks-template.md and checklist-template.md. Command templates live under templates/commands, and scripts are bundled for bash, powershell and python. Bundled extensions, including git and agent-context, are also carried inside the wheel and become installable through specify extension add.

The third piece is the integration. specify init takes an --integration flag, and the README's examples use copilot. The integration determines which agent the generated commands target. The repository has separate top-level directories for integrations, extensions, presets and bundles, which suggests the command surface is meant to be extended rather than fixed. The data flow is one-directional in the sense that matters: the agent reads the spec and plan files from the repository, and the artifacts it produces are committed alongside the code.

Installing Spec Kit and running the first spec

The README requires uv and tells you to install the CLI from a release tag, keeping the leading v. Replace vX.Y.Z with the latest release tag; the README gives v0.12.11 as a formatting example.

uv tool install specify-cli --from git+https://github.com/github/[email protected]

There is also a PyPI route, which the README offers as a preference question rather than a recommendation. The package name on PyPI is the same.

uv tool install specify-cli

With the CLI on the path, initialize a project and pick an integration. The README uses copilot in every quickstart.

specify init my-project --integration copilot
cd my-project

Launch your coding agent in that directory and run the commands in order. The constitution step is described as one-time per project, then specify, plan, tasks, implement, and converge. The README instructs you to repeat implement and converge until /speckit-converge reports Converged. That loop is the part worth internalizing: the agent does not declare victory on its own.

Two optional extensions follow the same install shape. The bug extension adds an assess, fix and test workflow, and the assess extension turns a raw idea into a go, needs-clarification or kill decision through intake, research, define, shape and decide.

specify extension add bug

The bug commands take a slug, for example /speckit-bug-assess "<bug report>" slug=login-crash, and the same slug is reused for the fix and test steps. The assess commands use the same pattern, for example /speckit-assess-intake "<idea>" slug=offline-mode.

Where Spec Kit stops being the right tool

The honest limitation is that Spec Kit governs process, not correctness. The README says convergence is reached when /speckit-converge reports Converged, but it does not document what that command checks or what evidence it weighs. Nothing in the repository's documentation suggests the CLI inspects your source tree and compares it to the specification. The verification is whatever the agent and the templates agree on, which means the quality of the spec is the ceiling on the quality of the result.

That makes the toolkit a poor fit for small work. A one-line fix or a dependency bump does not need a constitution, a plan and a task list, and generating them costs tokens and review time. The bug extension exists precisely because bug fixes are risky when an agent jumps from a report to a patch, but that extension is opt-in and adds three more commands to a workflow that was already six steps long.

There is also a maintenance cost hiding in the templates. The core pack is force-included into the wheel at build time, so the templates your project receives are a copy of whatever shipped in the version you installed. The README does not document rollback, and it does not describe how a project reconciles locally edited templates with a later release. If your team rewrites the spec template, you now own a fork of it. The 1.0.0 note about adaptability over stability points the same direction: expect the shape of the commands to keep moving.

Spec Kit compared with writing your own agent instructions

The realistic alternative is not another product. It is a hand-written AGENTS.md or a project rules file that tells the agent how you want work done. Spec Kit's repository contains an AGENTS.md of its own, and the toolkit generates agent context as part of init, so the two approaches overlap more than they differ.

The difference is structure and reuse. A hand-written rules file is a single document you maintain yourself, and it can say anything. Spec Kit instead installs a fixed sequence of commands with named artifacts at each stage, plus a constitution step that captures project principles once. That buys consistency across a team and across agents, because the same six commands exist whether you point them at Copilot, Claude Code or Cursor. It costs flexibility, because the stages are the stages.

Search interest in spec kit versus open spec, versus superpowers and versus bmad suggests people are comparing it with other spec-driven or agent-workflow projects. Spec Kit's distinguishing choice is that the specification is a versioned artifact in your repository and the process is delivered as commands the agent already knows how to invoke, rather than as a document you paste into a prompt.

Licence, releases and what upgrades cost you

Spec Kit is MIT licensed, which permits commercial and private use with the usual requirement to carry the licence text. That is a permissive licence with no copyleft obligation on your own code, and it says nothing about the licence of whatever your coding agent produces. This is a description of the licence file, not legal advice; check with your own counsel if the distinction matters to your organization.

Upgrade cost is the more practical question. The CLI is installed as a uv tool, so upgrading means reinstalling against a newer release tag. The README's installation guide is the place it points to for verification and upgrade methods, and the README itself does not spell those out. Because specify init writes templates and commands into the target project, a CLI upgrade does not automatically update projects that were initialized earlier. The README does not document a migration command for that case.

Release cadence is fast: v0.16.5 on 2026-08-19, v1.0.0 on 2026-08-21, and v1.0.1 the same day as the last push, 2026-08-21. The repository is not archived, and the last push was on 2026-08-21.

Editorial conclusion

Spec Kit fits teams already using a coding agent on multi-step work who want the requirements committed to the repository before implementation starts, and who can live with a template-driven process rather than an enforced one. It is the wrong tool for one-line fixes and for anyone expecting the CLI to validate that the code matches the spec, because it does not. Before adopting it, run specify init in a scratch directory and read the generated templates to see whether your team will actually maintain them.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes