Spec Kit · GitHub · as of September 30, 2026
GitHub Spec Kit writes unit tests for your requirements
Before any code exists, Spec Kit checks whether the spec is complete, clear and measurable. After the build, it checks the code against every requirement. Both follow from one idea: the spec, not the code, is the thing to get right.
This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.
Two philosophies at a glance
Spec Kit
Write down what and why before how, under a project constitution, then carry each feature’s spec through a plan and tasks to code that converges on it.
The Enso Method
Define the whole body of work first and keep its requirements true for the life of the system, while the people who decide confirm the open questions.
Where they differ
- Specs serve one change Specs live as long as the system Spec Kit sits toward “Specs serve one change”; the Enso Method sits at the “Specs live as long as the system” end.
- One change at a time The whole body of work up front Spec Kit sits toward “One change at a time”; the Enso Method sits at the “The whole body of work up front” end.
- Stops and asks Decides, records it, keeps going Spec Kit sits in the middle; the Enso Method sits at the “Decides, records it, keeps going” end.
- Passing tests are enough Every requirement proven against real systems Spec Kit sits in the middle; the Enso Method sits at the “Every requirement proven against real systems” end.
What they share
- Starts from a prompt Intent written down first Spec Kit sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.
- Built for one person Built for a team Spec Kit sits toward “Built for a team”; the Enso Method sits toward “Built for a team”.
Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.
Code serves the spec
“Specifications don’t serve code—code serves specifications.” That inversion opens Spec Kit’s methodology. If an AI can turn a precise description into working code, the description is the thing worth getting right, and “raw AI generation without structure produces chaos.”
So the structure lives in the templates. The spec covers what users need and why, never the tech stack; small gaps get stated defaults, and the spec may carry at most three open questions. A project constitution holds the principles every plan is checked against. And requirements are tested the way code is: “If your spec is code written in English, the checklist is its unit test suite.”
A constitution once, then five steps for every feature
- Constitution, once per project: the principles every later step is checked against.
- Specify: describe a feature and get user stories in priority order, numbered requirements and measurable success criteria, with no tech stack.
- Plan: name your stack. It researches the unknowns and writes a data model, interface contracts and a validation guide.
- Tasks: an ordered list with one phase per user story, the first story being the smallest useful release.
- Implement: build the tasks, phase by phase.
- Converge: check the code against every requirement and add each gap as a new task; repeat until it reports “Converged.”
Optional gates add questions and cross-checks for features with real ambiguity. The README sets the pace: “Invoke each /speckit-* skill in your agent’s chat, one at a time, and review the result before continuing.”
For teams that want one way of working, on any agent
Spec Kit fits a team that wants spec-first feature work to look the same whichever of about 40 coding agents each developer uses, and that wants to shape the process itself: swap a template, add a gate, package a setup for a role. It installs offline and behind firewalls.
It asks for Python, uv and a review of each document before the next step; its own “lean” preset is for teams that want the steps “without the ceremony of the full templates.” It suits you less for small fixes (its maintainers use it for substantial features, not every change) or for long unattended runs, where its docs warn that agents can lose track of the plan.
Where the Enso Method made a different call
Both write down what and why before how, research technical unknowns rather than asking, and check the result against every requirement. They part on three things.
What happens to the spec afterwards
Spec Kit
It leaves this to your team on purpose, describing three ways to keep specs: “None is the default.”
The Enso Method
One set of requirements and one design, the source of truth for the code, amended before any change to what the system should do.
Choose by situation: Spec Kit lets a team keep its own habits. The Enso Method keeps what should this system do? answerable for years, at the cost of amending documents as you go.
Who answers the open questions
Spec Kit
It records sensible defaults and asks whoever runs the command about the rest, a few questions at a time with suggested answers, and waits for the reply.
The Enso Method
Built for when the person who decides isn’t at the keyboard, it writes each business question up as a proposal and keeps building while the owner confirms or corrects it.
Choose by situation: if the decider runs the commands, Spec Kit’s questions are the shortest path to a right answer. If a client decides, the Enso Method keeps the build moving.
What counts as done
Spec Kit
Converge reads the code against every requirement, re-checks tasks already ticked off and flags code nobody asked for. Tests are optional: written when the spec, the user or the project’s constitution calls for them.
The Enso Method
Every acceptance criterion needs a test that would fail if the behavior were wrong, against real systems wherever they exist.
Choose by situation: Spec Kit’s check needs no test suite. The Enso Method’s standard costs more test-writing, and pays off where code that reads correctly fails against real systems.
Where Spec Kit shines
- One process on almost any agent. About 40 integrations, from Copilot to Claude Code; the Enso Method is built for Claude Code and Codex.
- Requirements checked before code exists. Checklists test the spec, and analyze cross-checks spec, plan and tasks without changing anything.
- A process you can reshape, with presets, workflows with approval gates, a catalog of 176 community extensions, and catalogs an organization can curate.
- Separate processes for bugs and ideas. A bug fix ends in a verdict, because “Missing verification is not a successful fix.” An idea assessment can end in a kill, which counts as a success.
How the Enso Method differs, and why
Spec Kit and the Enso Method both write intent down before code; they part over what happens to it afterwards. Spec Kit specifies one feature at a time and lets each team decide whether a spec lives on. The Enso Method plans the whole body of work, keeps its requirements current for the life of the system, and sends business questions to the people who decide as proposals, without stopping the build.
Get started
Spec Kit is free and open source (MIT). It runs on Linux, macOS and Windows with Python 3.11 or later and uv, and its install instructions are in the README at github.com/github/spec-kit.