Spec Kit Setup: Spec-Driven Development With Any AI Agent

Spec Kit is GitHub's open source toolkit for spec-driven development: you write an executable specification first, then let any AI coding agent generate the plan, the task list and the code from it. It picked up roughly 1,160 stars in a day on GitHub trending, on top of about 128,600 total, which makes it one of the largest developer tools on the platform. Setup takes around five minutes: install the Specify CLI with uv, run specify init, then drive the whole workflow from slash commands inside the agent you already use.

• One CLI, specify, installs from PyPI or a pinned Git tag and runs on Linux, macOS and Windows, with PowerShell scripts supported without WSL.
• 30+ agent integrations, including Claude Code, GitHub Copilot, Gemini CLI and Codex; specify integration list prints what your installed version supports.
• The workflow is a sequence of slash commands, from /speckit.constitution through /speckit.implement.
• MIT licensed and shipping fast: v0.16.4 landed on August 14, 2026, the fourth release in eight days.

What is Spec Kit and why is it trending?

Spec-driven development inverts the usual order. For most of software history the specification was scaffolding: you wrote it, you built from it, you threw it away, and the code became the only real record of intent. Spec Kit's argument is that once an AI agent is doing the typing, the specification stops being documentation and becomes the input. The repository's own framing is that specifications become executable, directly generating working implementations rather than just guiding them.

RelatedOpen Code Review Setup: Alibaba's Free AI Reviewer CLI

In practice that means a folder of artifacts inside your project: a constitution holding the principles the agent must respect, a spec describing what you want and why, a plan naming the stack, and a task list the agent works through. The project is heavily influenced by the research of John Lam, and GitHub positions it across three phases: greenfield builds from scratch, creative exploration where you generate parallel implementations across different stacks, and brownfield work where you add features to or modernize an existing system.

The trending spike is not about a single feature. It is what happens when a tool crosses from script to platform. Spec Kit now has three layers of customization on top of its core: extensions that add entirely new commands, presets that override how existing specs, plans and tasks are formatted, and bundles that package a curated set of both into a single versioned, role-oriented install for a product manager, a business analyst or a security researcher. The last few releases are mostly community catalog additions, which is the shape of a project whose users have started building on it rather than just using it.

How do you install the Specify CLI on macOS, Linux and Windows?

Prerequisites are short: Python 3.11 or newer, and either uv or pipx for package management. Git is now optional, required only when the git extension is enabled. Windows no longer needs WSL because the automation scripts ship as PowerShell variants. The same install command works on all three platforms.

The simplest route is the published PyPI package:

# recommended: install once, use everywhere
$ uv tool install specify-cli

# alternatives if you already live in one of these
$ pipx install specify-cli
$ pip install specify-cli

The maintainers' preferred route for teams is a source install pinned to a release tag, so everyone gets the same behavior. Keep the leading v on the tag:

# pinned to the current release
$ uv tool install specify-cli --from git+https://github.com/github/[email protected]

Then check the install and keep it current. Note the distinction the docs draw: specify version confirms the command is on your path and reports a version, but it does not prove which channel the executable came from.

$ specify version

# read-only, tells you if a newer release exists
$ specify self check

# preview an upgrade before running it
$ specify self upgrade --dry-run
$ specify self upgrade

How do you start a spec-driven project?

Initialization scaffolds the artifacts and writes the slash commands into your agent's directory. Pass your agent explicitly rather than relying on the default:

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

Documented integration values include claude, gemini, copilot, codebuddy, pi and omp, and specify integration list shows the full set for your version. Script variants are chosen the same way, with --script sh, --script ps or --script py; Windows defaults to PowerShell and everything else to Bash, and the scripts land in .specify/scripts/ under a matching subdirectory. If your agent supports skills mode, passing --integration-options="--skills" installs agent skills instead of slash-command prompt files.

From there the loop runs inside the agent. Most agents expose the commands as /speckit.*; Codex CLI and Command Code in skills mode use $speckit-* instead.

RelatedStrix Setup: Run an AI Penetration Tester on Your Code

# 1. the rules the agent must never break
/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

# 2. what you want, not how to build it
/speckit.specify Build an application that can help me organize my photos in separate photo albums

# 3. now the how
/speckit.plan The application uses Vite with minimal number of libraries

# 4. and 5.
/speckit.tasks
/speckit.implement

Four optional commands are worth knowing. /speckit.clarify hunts for underspecified areas and is recommended before planning. /speckit.analyze runs a consistency and coverage check across the spec, plan and tasks after /speckit.tasks and before you implement. /speckit.checklist generates quality checklists the docs describe as unit tests for English. /speckit.converge assesses the codebase against the artifacts and appends whatever work is still outstanding, which is the command that makes brownfield use viable.

How does it compare with just prompting the agent?

Plain prompting still wins on small, well-understood changes, where the ceremony costs more than it saves. The trade shows up on work where the requirements are genuinely uncertain: writing them down forces the disagreement to surface before a few thousand lines get generated on top of it.

What are the gotchas before you rely on it?

Five things worth knowing. First, non-interactive sessions such as CI runs or piped commands default to the GitHub Copilot integration unless you pass --integration, so always be explicit in automation. Second, bare specify self upgrade executes immediately with no confirmation prompt, matching the behavior of pip install -U and npm update; use --dry-run first if that is not what you want, and set SPECIFY_UPGRADE_TIMEOUT_SECS to cap how long the installer subprocess may run.

Third, the release cadence is genuinely fast, with v0.16.1 through v0.16.4 all shipping inside eight days, so pin a tag if you need reproducible behavior across a team. Fourth, community extensions, presets and bundles are independently created and maintained by their authors, and the README says plainly to review the source before installing and use at your own discretion; the bundle system does at least guarantee that specify bundle info shows exactly what specify bundle install will add. Fifth, this is still labelled an experimental effort by GitHub, aimed at validating a hypothesis about process rather than shipping a finished product, and the workflow is only as good as the specs you are willing to write.

Our take

The interesting thing about Spec Kit is not the templates, it is what the star count implies. A toolkit whose entire premise is write the requirements down first has become one of the most starred developer repositories on GitHub, which suggests a lot of people have independently hit the same wall: the agent is no longer the bottleneck, the ambiguity in your own head is. Spec-driven development is really just requirements engineering with a faster feedback loop, and the reason it feels new is that for the first time the specification produces something immediately instead of sitting in a wiki.

Where we would be careful is the ceremony. Seven core commands and a constitution is a lot of process for a bug fix, and the failure mode is teams generating elaborate specs for work that needed one sentence. Use it where the uncertainty is real. The other thing to respect is the experimental label: GitHub is explicit that this is research into a process, not a stable product surface, and the four releases in eight days back that up. Pin a version, skim the community components you install, and treat the specs as the artifact that matters, because the tooling around them will keep moving.

Original analysis by GenZTech. Tool documentation: github/spec-kit on GitHub.