Spec-Driven Development Tools Compared: Spec Kit, Kiro, BMAD, OpenSpec

The four spec-driven development tools most people compare are GitHub Spec Kit, Kiro, BMAD Method and OpenSpec, and they differ more in weight than in idea. Spec Kit is a thorough, fixed sequence of steps that works with many agents. Kiro is Amazon’s own agent with specs built into it, and the only one of the four that is not open source. BMAD is a larger method that scales its planning from a one-line change to a whole product, with briefs, requirements documents and architecture on the way. OpenSpec is the lightest: each change gets a small folder of documents, and when the change is done its spec is merged into a running description of the system. None of them is the best. Which one fits depends on how big your changes are, which agent you already use, and whether your code exists yet.

The method itself is in what is spec-driven development. Spec Kit and Kiro each have their own walk-through, in GitHub Spec Kit and what is Kiro. This page puts the four side by side.

The four in one line each

• Spec Kit, from GitHub: a Python command-line tool, specify, that installs a fixed set of speckit skills into your agent. MIT licence.
• Kiro, from AWS: an IDE, command line, web and mobile agent where specs are a built-in feature. Closed source.
• BMAD Method, from BMad Code: a set of skills covering planning, architecture, tickets and building, sized to the work. MIT licence.
• OpenSpec, from Fission AI: a Node command-line tool, openspec, that adds a change-by-change spec layer to your agent. MIT licence.

What each one produces

• Spec Kit: a project constitution in .specify/memory/constitution.md, then one numbered folder per feature under specs/ holding spec.md, plan.md and tasks.md, plus research.md, data-model.md, quickstart.md and a contracts/ folder when there are interfaces to describe.
• Kiro: per spec, a requirements.md of user stories with acceptance criteria (or a bugfix.md for a bug), a design.md with architecture and sequence diagrams, and a tasks.md. Separate steering files hold standing project rules.
• BMAD: whatever the chosen path needs. The planning skills write files such as brief-<slug>.md, prd-<slug>.md, architecture-<slug>.md and spec-<slug>.md; the ticket skill writes tickets.toml and story files; on an existing codebase a project-context skill writes a verified block into AGENTS.md.
• OpenSpec: per change, a folder under openspec/changes/ with proposal.md, a specs/ folder of requirement changes, design.md and tasks.md. Archiving the change merges its spec changes into openspec/specs/, which grows into a description of the whole system.

The last point is the real difference in output. Spec Kit and Kiro leave you with one spec per feature, frozen at the time it was written unless you choose to keep it current. OpenSpec writes each change as a delta, marked ADDED, MODIFIED or REMOVED, and folds it into a living spec when the change is archived. BMAD sits between them: its plans and specs are kept as context for later work rather than as a single system description.

The steps each one walks you through

• Spec Kit: constitution once, then specify, plan, tasks, implement and converge for each feature, with clarify, checklist and analyze as optional checks. Implement and converge repeat until converge reports no gaps.
• Kiro: requirements (or bug analysis), then design, then tasks, each approved before the next. A feature spec can start requirements-first or design-first, and a Quick Spec generates all three files without the approval gates. When you run the tasks, Kiro works out their dependencies and runs independent ones at the same time.
• BMAD: four paths by size. A trivial change is edited and verified; a one-session change goes straight to bmad-build; an epic-sized change runs bmad-spec, then bmad-ticket to cut stories, then a build per story; a project adds shared contracts and repeats the epic path. Every path ends in the same unit of work, a build session.
• OpenSpec: /opsx:explore to think it through (optional), /opsx:propose to write the change folder, /opsx:apply to implement the tasks, /opsx:archive to merge the spec and file the change away. An expanded profile adds steps such as /opsx:verify and /opsx:continue.

Two of these have been reworked recently, so older tutorials will not match. OpenSpec’s README describes a rebuilt workflow and its OPSX guide↗ (opens in a new tab) calls it the standard workflow now, with the old one kept as legacy. BMAD’s planning guide↗ (opens in a new tab) is organised around sized paths and named skills, and its existing-codebase guide says the project-context skill replaces the deprecated bmad-document-project workflow.

Which agents they work with

• Spec Kit: a long list of integration keys passed to specify init --integration, including GitHub Copilot, Claude Code, Codex, Gemini CLI, Cursor and Kiro CLI, and a generic option for anything else.
• Kiro: its own agent only, across the IDE, command line, web and mobile. It reads AGENTS.md, so shared rules still apply. Its model list includes Claude and GPT models and several open-weight models.
• BMAD: any coding tool that supports skills, installed with the skills command line, or as a plugin from a marketplace in Claude Code or Codex. Web bundles package some planning workflows for Gemini Gems and ChatGPT custom GPTs.
• OpenSpec: its README says more than 30 tools. openspec init writes skills or commands for the ones you pick and prints the right spelling for each, because Cursor and Copilot write /opsx-propose and Codex writes $openspec-propose.

Installation and licence

# Spec Kit: Python 3.11+ and uv
uv tool install specify-cli
specify init my-app --integration claude

# OpenSpec: Node.js 20.19+
npm install -g @fission-ai/openspec@latest
openspec init

# BMAD: Node.js, npm, Git and uv
npx skills add bmad-code-org/BMAD-METHOD
# then ask the bmad skill to run "bmad setup"

# Kiro: download the IDE or install the CLI from kiro.dev

Spec Kit, BMAD and OpenSpec are MIT-licensed and live in public repositories: github/spec-kit, bmad-code-org/BMAD-METHOD and Fission-AI/OpenSpec. Kiro’s public repository is, in its own words, an issue and feedback tracker; the Kiro README↗ (opens in a new tab) says the product source code is not hosted there. That matters less for day-to-day use than for what you can change: with the three open tools you can edit the templates and prompts, and OpenSpec’s OPSX workflow is built around a schema.yaml and templates you are expected to customise.

Existing code or a blank folder

Most real work is a change to something that already exists, so this is often the deciding question.

• OpenSpec is built for it. Its guide to existing projects↗ (opens in a new tab) says you write specs only for what you are about to change, and the specs fill in one change at a time. Deltas are the reason it works.
• Spec Kit adopts cleanly but does not document what you have. Its existing-project guide says to commit first, run specify init --here --force, and describe each change with the compatibility boundaries it must keep. It does not infer specs for existing behaviour.
• BMAD has an explicit route: the project-context skill writes verified instructions into AGENTS.md, and bmad-build investigates the repository and notes what to reuse and what not to change before it builds.
• Kiro can generate steering files for the project and has bugfix specs that start from current versus expected behaviour. Feature specs are per feature, whether the code around them is new or old.

Which one fits

• Spec Kit fits a team that wants the same thorough process across whichever agents its members use, and features big enough to justify nine steps. It is heavy for a one-line fix.
• Kiro fits someone who wants specs without assembling anything, and is happy to work inside Kiro’s own agent. It does not fit a team standardised on another agent.
• BMAD fits work that starts before the code does: product briefs, requirements, UX and architecture, then stories. It is the most to learn, and its sized paths mean you do not pay for that on small changes.
• OpenSpec fits established codebases and frequent small-to-medium changes, where a living spec that grows with the code is worth more than a thick document per feature.

Tessl often appears in lists like this. Its documentation↗ (opens in a new tab) now describes it as a platform for managing agentic development, built around a registry of skills and plugins, rather than a spec workflow of the kind compared here, so it is left out.

Where the tasks go afterwards

All four end in a task list inside the repository: tasks.md, tickets.toml or a tasks section of the change folder. That is the right list for the agent at work. It is the wrong one for the person deciding what is built next, who may never open the repository. The split that works with any of the tools is by level: the implementation steps stay in the file, and each outcome someone would check becomes one task on a shared board.

On fenbs that task has a note for the problem, which is the user story or change and the path to its spec, and a plan for how it will be done, rewritten as the agent learns. A question the spec leaves open goes on the Decisions page, where a person decides it. The agent sets the test status and notes when it finishes, and a person checks the result. fenbs reads none of these files and syncs with none of them; the assistant files and updates the tasks over MCP with fenbs_create_item and fenbs_update_item, and there are no epics or sprints to mirror a BMAD epic or a Spec Kit phase.