OpenSpec vs Spec Kit vs BMAD: Which Spec Framework Should You Pick?

OpenSpec, GitHub Spec Kit, and BMAD Method solve the same problem with three very different weights. OpenSpec is a lightweight, tool-neutral spec format. Spec Kit turns the workflow into CLI commands. BMAD Method is a full phase-based methodology with specialized agents. Kiro, AWS’s IDE, does something similar inside its own editor.

If you’re still not sure what belongs in a spec and why an agent reads it better than a prompt, start with what spec-driven development is and come back here. What follows assumes you already know that, and that the only question left is which one to install on Monday.

Framework	What it is	Best for	Ceremony it imposes
OpenSpec	An npm CLI plus a folder convention: each proposed change lives in its own directory with the proposal, requirements, and tasks	Adding specs to an existing repo without reorganizing anything	Low
GitHub Spec Kit	A toolkit that installs a slash-command workflow in your agent, from project principles all the way to implementation	Starting a feature with a clearly marked, step-by-step path	Medium. The flow is fixed, you decide how closely you follow it
BMAD Method	A phase-based methodology with specialized agents for product, architecture, UX, development, and testing, plus domain-specific modules	Projects where clarifying and planning carry as much weight as coding	High
Kiro (AWS)	An IDE that generates `requirements.md`, `design.md`, and `tasks.md` before you touch any code	Teams already working inside the AWS ecosystem	Medium, but tied to the editor

OpenSpec: The One That Forces You to Change the Least

OpenSpec is a markdown spec format with a CLI that organizes them, and its own repository states it’s built «for brownfield not just greenfield»^[2]. That phrase is the main reason to pick it. Most of us don’t start projects from scratch: we inherit a six-year-old repository that needs specs bolted on without asking permission to reorganize it.

It’s maintained by Fission-AI and installs like any npm package.

# Instalar y preparar el repositorio (crea openspec/specs y openspec/changes)
npm install -g @fission-ai/openspec@latest
openspec init

# Y dentro de tu agente, los comandos del ciclo:
#   /opsx:explore   piensa en voz alta antes de comprometerte a nada
#   /opsx:propose   crea la carpeta del cambio: proposal.md, specs/, design.md, tasks.md
#   /opsx:apply     el agente implementa contra esas tareas
#   /opsx:archive   el cambio pasa a formar parte de la spec viva

The mental model is that of a pull request, but for the contract instead of the code. A change in progress lives in openspec/changes/; once it’s done, it gets archived and its requirements move into openspec/specs/, which is the snapshot of how the system behaves today. That separation between what you want to change and what’s already true solves spec drift by design: there’s no giant document slowly going stale, just proposals that get closed out.

It’s tool-neutral and supports more than thirty agents^[2]. If you swap Claude Code for Cursor tomorrow, the files are still there and still work.

GitHub Spec Kit: The Workflow Turned Into Commands

Spec Kit turns the spec-driven development cycle into slash-commands that your agent runs in order. It’s the project with the most traction of the three, by a wide margin: it passed 126,000 stars on GitHub in August 2026^[1], and it comes from GitHub itself, which doesn’t make it better but does make it more likely your team will accept it without an argument.

# Requiere uv (gestor de paquetes de Python); vX.Y.Z es la release que fijes
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init mi-proyecto --integration copilot

From there, the flow is /speckit.constitution to lock in the non-negotiables, /speckit.specify for the what, /speckit.plan for the technical how, /speckit.tasks to break it down, and /speckit.implement to execute^[1]. I cover that cycle in detail in the complete guide to spec-driven development, so I won’t repeat it here.

What’s worth pointing out is the commands almost nobody mentions, which are the ones you actually use after the first week. /speckit.clarify forces you to resolve what you left ambiguous before the agent makes something up. /speckit.analyze cross-checks spec, plan, and tasks for inconsistencies between them. /speckit.converge evaluates existing code against the spec and fills in what’s missing, which is the entry point for an already-running repository. And /speckit.taskstoissues dumps the tasks into GitHub issues, handy if your team already lives there.

It supports more than thirty coding agents, including Claude Code^[1]. The price of all that convenience is that the path is fixed: if your team already has its own way of writing requirements, Spec Kit is going to push back.

BMAD Method: Phases, Agents, and More Model Calls

BMAD Method isn’t a file format, it’s a full work process with roles split up. Its delivery loop has four named phases: clarify, plan, build and verify, and learn and adjust, which loops back into planning^[3]. Each stretch is covered by a specialized perspective (product, architecture, UX, development, testing), and on top of the core there are modules for specific domains, from test architecture to game development.

It installs with npx bmad-method install, it’s on version 6, and it’s published under the MIT license^[3]. Its repository is explicit that it’s free, with no paid tiers.

Now, free doesn’t mean cheap. That’s the nuance that gets lost in almost every comparison you’ll read: the software costs nothing, but a method that routes your idea through several agents across separate phases makes far more model calls than writing a markdown file and running it. More phases and more roles mean more input and output tokens per feature. I’m not going to give you a dollar figure per month, because it depends on the model you use, your volume, how many modules you enable, and how much context each phase carries forward. Any number you read without those variables is made up. Measure your own usage for a week before you commit the team to it.

Which One to Pick for Your Situation

Before comparing feature sets, work out how much ceremony your team will still be sustaining two months from now. A framework nobody follows is worth less than a markdown file everyone keeps updated.

Your situation	What I’d pick
A repo with years of history, you want to start documenting contracts without touching the structure	OpenSpec
New project, small team, you want a marked path and no arguing about process	GitHub Spec Kit
Product with many stakeholders, requirements you have to defend to someone, or a regulated environment where the decision trail matters	BMAD Method
Your team already lives in the AWS ecosystem and doesn’t mind being tied to the IDE	Kiro

For a team of two or three people, BMAD is usually too much. The agent-coordination overhead it solves belongs to an organization you don’t have: you end up filling out analysis artifacts for a feature that would’ve fit in a single ticket. The reverse happens too. If you’re building something with requirements someone outside will audit, OpenSpec’s loose markdown will leave you without the trail you need.

And there’s an option nobody’s selling you, because it doesn’t sell anything: all three produce markdown files versioned in git. You can start with OpenSpec, steal BMAD’s idea of separating analysis from implementation, and never install a single line of BMAD. The specs are yours. The framework is on loan.

Two Mistakes When Adopting Any of the Three

Adopting the Ceremony Before the Habit

Installing the most complete framework when your team isn’t already writing specs is the fastest way to guarantee nobody writes specs. The tool doesn’t create the habit, it formalizes it. If none of your last four features shipped with written acceptance criteria, that’s the problem to solve, and you solve it with a markdown file, not six agents.

Confusing the Framework With the Spec

The framework generates the structure. What makes a spec actually useful is still the content: external behavior, invariants, integration contracts, and validation criteria a test can run. A proposal.md generated by an agent and reviewed by nobody is exactly as useless as the prompt it replaced — it just takes up space in the repo now and gives you false confidence.

Directing agents with good judgment is the underlying skill, and no CLI installs that for you. If you’re interested in systematizing how you work with AI agents beyond specs, in AI Agent Design Patterns we cover the patterns for designing reliable workflows.

Checklist Before Adopting One

You’ve written at least two specs by hand, no tooling, and they’ve survived a review.
You know which folder in the repo the files will live in and who reviews them.
The framework supports the coding agent your team already uses.
You’ve measured the API spend of a full feature with the workflow in place.
There’s a written rule for when you do NOT write a spec.
If you drop the tool tomorrow, the files left behind are still readable.

Sources

github/spec-kit, official repository — toolkit description, installation via specify-cli, list of slash-commands, and support for more than 30 coding agents. Star count checked in August 2026.
Fission-AI/OpenSpec, official repository — installation via npm, /opsx:* commands, the openspec/specs and openspec/changes organization, and the statement «built for brownfield not just greenfield».
bmad-code-org/BMAD-METHOD, official repository — delivery loop phases, available modules, installation with npx bmad-method install, and MIT license.

Frequently Asked Questions

Do I have to pick just one?

No, and in fact mixing usually beats marrying one. All three write markdown into your repo, so you can use OpenSpec day to day and borrow BMAD’s discipline of separating the clarification phase from implementation without ever installing BMAD. What I don’t recommend is running two tools generating files in parallel on the same repo, because you end up with two versions of the contract and neither one is authoritative.

Which is the easiest to start with today?

OpenSpec. One npm install -g @fission-ai/openspec@latest and an openspec init get your repo ready in a minute, and the first proposed change comes out of a single command inside your agent.

Do they work with Claude Code?

Yes, all three. Spec Kit claims support for more than thirty coding agents, Claude Code among them, and OpenSpec quotes the same number of compatible tools. BMAD installs into the project and its flows get run by whichever agent you use. Whether they work with your agent isn’t the deciding factor: by 2026 they all do.

Spec Kit or OpenSpec?

It depends on whether the project is new or already exists. You’ll sometimes see Spec Kit’s name written lowercase as «open spec», but it has no relation to OpenSpec: they’re two separate tools. Spec Kit sets a complete path from project principles through implementation, designed mainly for starting something new with structure. OpenSpec doesn’t impose that path: it’s the option when you want to add specs to an already-existing repo without reorganizing anything. If you’re unsure, this is the deciding question: are you starting from zero, or documenting something already running?

What is BMAD Method?

It’s an AI-assisted development methodology organized into four phases (clarify, plan, build and verify, learn and adjust) with agents specialized by role: product, architecture, UX, development, and testing. Unlike OpenSpec (a file format) or Spec Kit (a command flow), BMAD is a full process, which is why it imposes the most ceremony of the three.

And what about Kiro?

Kiro is AWS’s IDE that generates requirements.md, design.md, and tasks.md before you write any code. It plays in a different category because it’s not a layer on top of your agent but the entire editor, so adopting it feels more like switching your working tool than installing a package. I mention it briefly in the definition of spec-driven development, which is where the detail on how it works actually lives.

Which one burns the most tokens?

BMAD Method, by a wide margin, because its loop routes every change through several phases with different agents, and each one consumes input context and produces output. OpenSpec sits at the other extreme: the spec is a markdown file and the agent reads it the same way it would read any other file in the repo. It’s a cost that pays off when the analysis is worth as much as the code, and doesn’t when the feature would’ve fit in a ticket.