One of these tools no longer ships the thing it was famous for, and its own changelog is where you find that out.
Here is the plain version. There are now five serious tools that promise to give you spec-driven development: GitHub's Spec Kit, AWS's Kiro, OpenSpec, BMAD-METHOD and Tessl. They are not five versions of the same product. Three of them are markdown files and a scaffolder, one is a commercial IDE, and one has quietly become something else entirely. Knowing which is which changes what adopting any of them costs you.
We run the loop described in our spec-driven development piece on client work, and we have installed none of these five. That is the reason this page exists rather than a reason to distrust it.
Everything below is read from vendor docs, licence files and release data on 11 August 2026, plus the one independent teardown worth citing. No hands-on ranking, no winner, no speed claims. We do not need any of these to be the right answer, which is a position none of the pages competing for your attention can occupy.
Most of them are not the thing you think they are
The category name suggests five products. What is actually on offer is three different shapes, and the shape determines the adoption cost far more than the feature list does.
The first shape is a command-line tool that writes markdown into the coding agent you already run. Spec Kit installs slash-command templates. OpenSpec's CLI never calls a model at all. BMAD installs agent-persona files into your project. Nothing here replaces your editor or your agent; it supplies structure and vocabulary, and you keep everything else.
The second shape is a commercial product with the method built into it. That is Kiro: proprietary, its own surfaces, its own pricing. You are buying a place to work, not a set of templates.
The third shape is a tool that used to be an SDD tool. That is Tessl, and it is the most useful thing on this page.
What each one actually is
Comparable, not ranked. We have no basis for a verdict and neither does anyone who has not run all five in anger.
| Tool | Who ships it | What it is | Licence | Who it suits |
|---|---|---|---|---|
| Spec Kit | GitHub | CLI that installs slash-command templates into your agent | Open source | Shops that mix coding agents and want one spec set to drive all of them |
| Kiro | AWS | Commercial agentic IDE with the method built in | Proprietary | Teams that need procurement, SSO, RBAC and audit more than they need templates |
| OpenSpec | Fission-AI | CLI built around delta specs; never calls a model itself | Open source | Brownfield codebases you cannot afford to back-document first |
| BMAD-METHOD | BMad Code | Installs named agent personas across a phased workflow | Open source, trademark carve-out | Solo builders and small teams who want the ceremony supplied rather than invented |
| Tessl | Tessl AI | Now a registry and agent-enablement platform; the spec framework is gone | Proprietary | Orgs governing agent context across many repos, which is a different purchase |
The licence column is worth a second look if you are choosing on openness. BMAD's grant excludes its word marks and logo, which is why GitHub's own API reports the repository licence as NOASSERTION rather than MIT. That is a perfectly normal thing for a project to do. It is not what most people assume when they read the word open on a roundup page.
What the changelogs say and the roundups do not
This is the part you cannot get from a launch post, because it is only visible if you read the release history rather than the announcement.
Take the Tessl entry on its own terms, because it is the sharpest fact in the category. Tessl was one of three tools in the canonical independent review of this space. Its own CLI changelog records the pivot: the CLI was rebuilt as an agent-enablement platform, work on the framework was paused, and the framework functionality is no longer included, with the old version left available for anyone who needs it.
A vendor is allowed to change direction. The point for a buyer is that the thing being reviewed and recommended a few months ago is not the thing you would install today.
Set the three together and the pattern is the argument. Spec Kit is iterating hard, which is healthy for a young tool and expensive for whoever wrote your team runbook. BMAD is willing to break things inside a minor version. Tessl removed the feature the category is named after.
The practice has been stable for a year. The tool layer underneath it has not.
That asymmetry is the actual adoption risk, and it is the whole case for keeping your process portable. Whatever you adopt, the specs, the acceptance criteria and the review discipline should survive the tool going away, because on this evidence some of them will.
The teardown everyone cites is partly out of date
If you have read anything sceptical about these tools, you have read Birgitta Böckeler's comparison on Martin Fowler's site, published 15 October 2025. It is still the best independent writing on the subject and it is worth your time.
Two things about it get misreported. It covers Kiro, Spec Kit and Tessl. It does not cover OpenSpec and it does not cover BMAD, which is worth knowing before you cite it as a five-way verdict.
And ten months is a long time here. Her complaint about generated verbosity predates several Spec Kit releases. Her Kiro criticism predates the lighter-weight paths AWS has since added. And the Tessl framework she reviewed no longer ships at all. What survives is the part no vendor has solved: the proportionality problem, where a four-line bug fix triggers a full specification pipeline. We have not re-tested any of it, which is why this section reports what moved rather than rescoring anything.
What all five are actually selling
Strip the branding and the same three things are on offer everywhere. A human approval gate before code exists. Planning artifacts that live in version control instead of a chat history. A persistent context file so the agent stops relitigating your conventions every session.
That is the real product. Naming it that way reframes the decision, because those three things are not the exclusive property of any tool. They are a way of working, and a tool is one way to get there. We get them from a written task with acceptance criteria and tests, reviewed before anything is generated, which is the loop the anchor piece walks through end to end.
When a tool earns its place
This is not an argument against tooling, and a page that pretended otherwise would be sour grapes from a team that happens not to use any. There are cases where reaching for one of these is clearly correct.
Take Kiro if your blocker is organizational rather than methodological. Procurement, single sign-on, role-based access, centralised billing and an audit trail are things a markdown file genuinely cannot give you, and that is the one capability on this page that no amount of discipline substitutes for.
Take OpenSpec if you are working in a large existing codebase. Its delta-spec model is designed for describing a change against a system rather than describing the whole system first, which is the specific place generic spec-first workflows fall down hardest.
Take Spec Kit if your team mixes coding agents and you want one set of specs driving all of them, with switching handled for you rather than reimplemented per agent.
Take BMAD if you would rather be handed the ceremony than invent it, and you can carry its toolchain.
And skip all of them for a four-line bug fix, a two-person team, or a shop that would genuinely rather review code than review markdown. That last preference is legitimate, it is the core of the strongest published criticism of this whole category, and no tool on this list resolves it.
FAQ
Do you need a tool for spec-driven development? No. The practice is a written task with acceptance criteria and tests, agreed before anything is generated. That works in any editor with any agent. Tools supply structure, vocabulary and scaffolding, which is genuinely useful when a team is starting out or standardising across many repos.
What are the main spec-driven development tools? GitHub's Spec Kit, AWS's Kiro, OpenSpec from Fission-AI, BMAD-METHOD, and Tessl, though Tessl has since removed its framework and repositioned. Three of the five are command-line tools that write structure into the coding agent you already use rather than replacing it.
Is Spec Kit free? Spec Kit is open source and published by GitHub, so there is no licence cost. The real cost is the workflow it imposes and the churn in that workflow: it shipped six releases in the twelve days to 10 August 2026, which is healthy iteration and also a moving target for your internal documentation.
Is BMAD open source? The code is under an open licence, but the word marks and logo are excluded from the grant, which is why GitHub's API reports the repository as NOASSERTION rather than a standard licence identifier. You can use and modify the project; you cannot use its branding in a way that implies endorsement.
What is the difference between Spec Kit and Kiro? Shape, not features. Spec Kit is a command-line tool that installs templates into whichever agent you already run, so you keep your editor. Kiro is a commercial product from AWS with the method built into its own surfaces, so you are adopting a place to work rather than a set of files.
Which of these work on an existing codebase? OpenSpec is the one designed for it, because its delta-spec model describes a change against a system rather than requiring the whole system be specified first. Brownfield friction is the most commonly reported weakness of spec-first workflows generally, so treat any tool's greenfield demo with care.
What happened to Tessl's spec framework? Tessl rebuilt its CLI as an agent-enablement platform and paused framework development. Its own changelog states that the framework functionality is no longer included, with version 0.28.0 left available for anyone who still needs it. The product is now oriented around a registry and agent integration.
Can you do spec-driven development with Claude Code or Cursor? Yes, and the practice is agent-agnostic by design. A coding agent is not a spec-driven development tool; it is the thing that consumes the spec. The discipline lives in the written task and the tests, which is why it survives switching agents.
One concrete action
Before you adopt any of them, write one task file by hand: the behaviour, what is out of scope, and the three or four tests that prove it, then review that file before a line is generated. If that file makes the next build pass go better, you have the practice and you can shop for a tool that fits it. If it does not, no tool on this page was going to rescue it, and you have found that out for the price of an afternoon.
How 2muchcoffee runs this loop for clients
We build production software with the loop the anchor piece describes, without a framework, because the discipline is the part that transfers and the tooling underneath it keeps moving. If your team is standardising how it works with coding agents and cannot tell whether it needs a tool or a habit, that is the conversation worth having before you commit a quarter to either.
The plain way in is the AI and engineering work we do.
