Spec-driven development tools compared (2026)
Five tools, each described from its own documentation on 14 November 2026: what it calls a spec, where the spec lives, and what checks the spec before an agent builds from it.
How this comparison was made
We build software in the neighboring space, so this page follows the rules we apply to every comparison we publish. Each tool is described from its own documentation or repository, read on 14 November 2026, and paraphrased. We describe what each tool says it does. We have not run a head-to-head trial, and we say so again at the end.
The tools are compared on three things a buyer can check: what the tool is, what it calls a spec and where that spec lives, and what its documentation says checks the spec before an agent builds from it.
Three levels, one useful vocabulary
Birgitta Böckeler's October 2025 analysis on martinfowler.com gave the field its most-used distinction:
- Spec-first. A spec is written up front and used for the task at hand.
- Spec-anchored. The spec is kept after the task and used to evolve and maintain the feature.
- Spec-as-source. The spec is the main file over time. People edit the spec, and the code is generated from it.
Every tool below is at least spec-first. They differ in how long the spec is meant to live and how much process surrounds it.
Five spec-driven development tools, from their own documentation
| Tool | What it is | What a spec is, and where it lives | What checks the spec, per its documentation | Form |
|---|---|---|---|---|
| GitHub Spec Kit | An open-source toolkit from GitHub: a command-line tool, templates and slash commands that add a spec-first workflow to the coding agent you already use. | Markdown artifacts in the repository, one per phase (spec, plan, tasks), governed by a project “constitution” of principles. | Quality checklists and cross-artifact analysis are listed as built in. GitHub's launch post asks the person to verify at every phase. The README shows a converge step repeated after implementation. | MIT license. More than 30 agent integrations. |
| Kiro | An IDE and command-line tool with a built-in Specs workflow. | requirements.md in EARS notation and design.md, with tracked implementation tasks. Workflows start from requirements or from design. |
Analyze Requirements, run after requirements are generated and before design, checks for logical inconsistencies, ambiguities, conflicting constraints and gaps. | Commercial product. |
| Tessl | A framework for defining what to build before coding, plus a registry of specs for open-source libraries. | Specs stored in the codebase as lasting memory: a component description, capabilities with linked tests, and a public API. Tags mark code to generate from a spec, or a spec that documents existing code. | Specs are paired with tests that act as guardrails, so existing functionality is not broken. | At launch in September 2025: framework in closed beta; registry in open beta with more than 10,000 specs. |
| OpenSpec | An open-source spec layer from Fission-AI, described by the project as built for existing codebases as well as new ones. | A folder per change holding a proposal, specs with concrete scenarios, a design document and a task checklist. | The agent drafts the artifacts and a person reviews the plan before any code is written. Any artifact can be updated at any time. | MIT license. More than 30 coding tools. |
| BMAD Method | An open-source framework for taking an idea or change request to working software, with process depth that scales to the size of the work. | Briefs, specifications and architecture, carried forward as context from planning into build. | Specialized perspectives covering product, architecture, UX, development and testing, with multi-agent discussion, in a loop of clarify, plan, build and verify. | MIT license. Stable version 6.12 at review. |
| Spec2TestAI | Not a spec-driven development framework. It works upstream of the tools above, on the requirement they start from. | The requirement itself, from Jira or Azure DevOps, with the decisions made about it kept in a project knowledge base. | 32 quality measures on every story. Open questions go to people who can decide. Each answer is recorded with who decided and when. | Commercial. Delivers approved context to coding tools over MCP. |
One row here is ours, and it is not a like-for-like entry: Spec2TestAI does not replace the planning and task steps these tools provide. It is in the table to show where it sits relative to them.
What independent reviewers add
Vendor pages describe intent. Two independent sources describe use.
Böckeler tried Kiro, Spec Kit and Tessl in September 2025. She found Kiro the lightest of the three and mostly spec-first; Spec Kit also spec-first, with a branch created per spec; and Tessl the only one of the three explicitly aiming to keep specs over time and exploring spec-as-source. She also reported that the generated documents were long to review, and that agents did not always follow the instructions in them.
Thoughtworks placed Spec Kit in the Assess ring of its Technology Radar in April 2026, based on teams using it mostly on existing systems. Those teams found a constitution most useful when it captured project scope, domain context, technology versions, coding standards and repository structure. The Radar also describes OpenSpec's focus on spec deltas, which describe a change without first writing a complete specification, as well suited to existing systems.
How to choose
- You want to keep your current coding agent. Spec Kit, OpenSpec and BMAD Method are agent-agnostic toolkits. Kiro is its own environment.
- You are changing an existing system. OpenSpec is organized around changes to what already exists. Thoughtworks' teams used Spec Kit this way too, with customization.
- You want the requirements text itself analyzed. Kiro documents a dedicated analysis step for this.
- You want the spec to outlive the task. Tessl is built around specs kept in the codebase and paired with tests.
- You want role-based planning before build. BMAD Method structures the work around product, architecture, UX, development and testing perspectives.
The question the table cannot answer
All five tools start from a description that a person types. They can structure it, check it against itself and hold an agent to it. Whether “search responds within two seconds” is the number the business actually decided is a question for a person, and whether a new spec contradicts something decided last quarter depends on a record of decisions existing somewhere.
That is the subject of a companion piece, Spec-driven development: who checks the spec?, and it is the part of the problem Requirements Intelligence and Specification Intelligence work on.
What we have not tested
We have not run these tools against each other, and nothing here is a performance claim. Star counts, version numbers and beta status change monthly; we left out star counts for that reason, and the versions and statuses shown are as of the review date or the dated source. If a row is out of date, tell us and we will correct it with the date of the change.
Sources
- GitHub Spec Kit: repository README and documentation (page updated 16 July 2026); Delimarsky, D., launch post, GitHub Blog, 2 September 2025.
- Kiro documentation, “Feature Specs”, page updated 4 August 2026.
- Maple, S., “Tessl launches spec-driven framework and registry to make AI coding agents reliable”, Tessl, 23 September 2025.
- OpenSpec, repository README, Fission-AI.
- BMAD Method, repository README.
- Böckeler, B., “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl”, martinfowler.com, 15 October 2025.
- Thoughtworks Technology Radar: “GitHub Spec Kit” (15 April 2026) and “OpenSpec”.
Get your backlog scored
Send one backlog. We score it on 32 measures, find the conflicts across the stories, and list the questions nobody has answered yet. Fixed fee.
See the Quality Risk Audit