Resources / Compare
Spec Kit vs OpenSpec vs BMAD vs Kiro vs Agent Skills.
A comparison of some of the best-known and most used spec-driven development frameworks. Each one gives you a working method for building software with coding agents.
- 5 tools
- 27 criteria
- Sources checked 16 September 2026
The lineup
- 01GitHub ↗
Spec Kit
Puts a constitution at the project root, then a spec, a plan and a task list behind every feature.
OpenSpec
Each modification gets one change folder, and its delta specs merge back into a library that describes what the system does today.
BMAD Method
Everything runs through one build session. Bigger work wraps that session in a spec, then a PRD and an architecture spine, and repeats it as often as it needs to.
- 04AWS ↗
Kiro
The spec workflow, the agent, the hooks and MCP all live inside one AWS product, available as an IDE, a CLI, and web and mobile apps.
Agent Skills
Two dozen skills that encode senior-engineer practice and load on demand. They sit on top of whatever spec workflow you already run.
The comparison
27 criteria in four groups. Uncheck a column to narrow the table down to the two or three you are deciding between.
Columns5 of 5 shown
Built in Partial, or through an extension Not built in Does not apply
The shape of the workflow
What each tool treats as one piece of work, and what it leaves behind on disk when that piece is done.
| Criterion | Spec KitGitHub | OpenSpecFission AI | BMAD MethodBMad Code | KiroAWS | Agent SkillsAddy Osmani |
|---|---|---|---|---|---|
| Unit of workThe thing you point it at. | One feature, on its own branch | One change to an existing system | One build session, at every size. An epic or a product wraps that same unit and repeats it | One feature, or one bug | One task the agent is about to start |
| What one unit producesThe artifacts a human has to read and approve. | A spec, a plan and a task list, plus contracts and research notes | A proposal, a delta spec, a design note and a task list | A commit and an implementation record at the small end. Add a SPEC.md, then a PRD, UX docs and an architecture spine as the work grows | requirements.md (or bugfix.md for a bug), design.md and tasks.md | Nothing by default. The spec skill writes a spec file when you ask it to; the rest change how the work is done |
| Where the artifacts live | specs/<nnn-feature>/
.specify/memory/constitution.md | openspec/specs/
openspec/changes/
openspec/changes/archive/ | _bmad-output/specs/spec-<slug>/
_bmad-output/implementation-artifacts/
_bmad/custom/Output folder chosen at install; _bmad/ holds shared config and skill overrides | .kiro/specs/<feature>/
.kiro/steering/ | No artifact folder of its own. The skills install into .claude/skills/, or the matching folder for whichever of the 70+ agents you run |
| CeremonyHow much process runs before any code gets written. | Medium: five named stages, plus three optional commands | Light (propose, apply, archive) | Whatever you ask for, since nothing is mandatory. One sentence to build, or a full document suite for a multi-epic project | Medium. Requirements, design and tasks are approved in turn, and a Quick Spec path skips the gates | Light. A skill loads only when the task calls for it |
| Named agent personasSeparate agents with their own scope, handing artifacts to each other. | Spec Kit — Named agent personas: NoOne agent, many commands | OpenSpec — Named agent personas: NoSingle-agent by design | BMAD Method — Named agent personas: PartialFive ship (Analyst, Product Manager, Architect, Developer, UX Designer), but they are optional, and the workflow runs on skills rather than on handoffs between them | Kiro — Named agent personas: NoOne agent; independent tasks fan out in parallel | Agent Skills — Named agent personas: PartialA few personas ship alongside the skills, with no handoffs between them |
| Project-wide rules fileThe non-negotiables every feature inherits without being told. | Spec Kit — Project-wide rules file: YesThe constitution, loaded into every spec and plan | OpenSpec — Project-wide rules file: YesContext and rules in openspec/config.yaml, injected into every artifact | BMAD Method — Project-wide rules file: YesA verified block in your AGENTS.md, maintained by bmad-project-context | Kiro — Project-wide rules file: YesSteering files, shared across the IDE, CLI, web and mobile apps; AGENTS.md works too | Agent Skills — Project-wide rules file: NoComposes with whatever AGENTS.md you already keep |
Commands and checkpoints
Where the workflow stops and waits for a human, and what you get for keeping the spec and the code in step afterwards.
| Criterion | Spec KitGitHub | OpenSpecFission AI | BMAD MethodBMad Code | KiroAWS | Agent SkillsAddy Osmani |
|---|---|---|---|---|---|
| Core commands | /speckit.constitution
/speckit.specify
/speckit.plan
/speckit.tasks
/speckit.implement
/speckit.convergeSix core commands. Clarify, analyze and checklist are optional; taskstoissues opens GitHub issues | /opsx:explore
/opsx:propose
/opsx:apply
/opsx:update
/opsx:sync
/opsx:archiveThe core profile. The expanded one adds new, continue, ff, verify, bulk-archive and onboard | bmad-help
bmad-spec
bmad-build
bmad-code-review
bmad-retrospectiveFive of the sixteen delivery skills in the BMad Method module, on top of eight core skills | No slash commands. Requirements, design and tasks are stages in the spec workflow | A skill fires when the task matches its description; the Claude Code plugin adds slash commands (/spec, /plan, /build, /test, /review, /ship…) |
| Review gate between spec and designWhether you can correct the requirements before the agent reasons about how to build them. | Spec Kit — Review gate between spec and design: YesSeparate commands, so the spec exists before the plan does | OpenSpec — Review gate between spec and design: PartialPropose writes the planning artifacts in one pass; the expanded profile creates them one at a time | BMAD Method — Review gate between spec and design: PartialEach skill is its own workflow, so you can gate between them. Nothing forces an order, though, and a Story Breakdown lets you waive the stop per story | Kiro — Review gate between spec and design: YesRequirements, then design, then tasks, each approved in turn | Agent Skills — Review gate between spec and design: N/AThere is no pipeline to put a gate in |
| Delta specsADDED, MODIFIED and REMOVED markers, so a change is a diff rather than a rewrite. | Spec Kit — Delta specs: No | OpenSpec — Delta specs: YesThe mechanic the whole framework is built on | BMAD Method — Delta specs: NoNo delta markers. A spec is rederived from an append-only .memlog.md of decisions instead | Kiro — Delta specs: No | Agent Skills — Delta specs: No |
| Specs compound into a system descriptionWhether the folder ends up describing what the system does, or only what each change did. | Spec Kit — Specs compound into a system description: PartialSpecs are scoped per feature and stay that way | OpenSpec — Specs compound into a system description: YesArchived deltas merge back into openspec/specs/ | BMAD Method — Specs compound into a system description: PartialThe architecture spine and PRD are per project, and .memlog.md compounds within one spec. The AGENTS.md context block is refreshed rather than accumulated | Kiro — Specs compound into a system description: PartialOne folder per feature, kept in version control | Agent Skills — Specs compound into a system description: NoSkills shape the work; they keep no library of their own |
| Brownfield entry pointA first-class way to start on a codebase that already exists. | Spec Kit — Brownfield entry point: PartialConverge assesses the codebase against the artifacts | OpenSpec — Brownfield entry point: YesBuilt for it. Every change is a diff against what is already there | BMAD Method — Brownfield entry point: YesPoint bmad-build at a small change and it follows the conventions it finds. bmad-project-context writes a verified AGENTS.md block first, but it is optional | Kiro — Brownfield entry point: YesThe design stage reads your codebase before proposing anything | Agent Skills — Brownfield entry point: YesNothing to bootstrap, because the skills apply to whatever the repo already is |
| Mid-project scope changeA workflow for "we just learned something, let's replan". | Spec Kit — Mid-project scope change: No | OpenSpec — Mid-project scope change: YesUpdate revises the planning artifacts and ripples the edit in any direction | BMAD Method — Mid-project scope change: YesCorrect-course analyzes the impact and writes a sprint change proposal | Kiro — Mid-project scope change: No | Agent Skills — Mid-project scope change: N/A |
| Specs shared across reposWhether one change can span several repositories without copying the spec into each one. | Spec Kit — Specs shared across repos: PartialThe monorepo case is documented (one .specify/ per subproject). Separate repos are left to you | OpenSpec — Specs shared across repos: YesStores put openspec/ in a repo of its own that many code repos reference read-only. Still beta, and OpenSpec never clones, pulls or pushes for you | BMAD Method — Specs shared across repos: NoPlanning lives in the repo it belongs to | Kiro — Specs shared across repos: PartialThe web agent takes multi-repo tasks, but .kiro/ specs stay per repo | Agent Skills — Specs shared across repos: N/ASkills install per repo and keep no spec library to share |
What else is in the box
This group covers review, tests, automation, and how each tool connects to the rest of your stack.
| Criterion | Spec KitGitHub | OpenSpecFission AI | BMAD MethodBMad Code | KiroAWS | Agent SkillsAddy Osmani |
|---|---|---|---|---|---|
| Built-in code review | Spec Kit — Built-in code review: PartialCross-artifact consistency rather than a code reviewer; extensions add one | OpenSpec — Built-in code review: No | BMAD Method — Built-in code review: YesFive named lenses (adversarial, edge case, verification gap, structure, prose), then a triage pass that discards claims it cannot confirm in the code | Kiro — Built-in code review: PartialValidation runs tests rather than reading the diff | Agent Skills — Built-in code review: YesReview, simplification and security-hardening skills, each demanding evidence |
| Built-in test generation | Spec Kit — Built-in test generation: No | OpenSpec — Built-in test generation: No | BMAD Method — Built-in test generation: Yesbmad-qa-generate-e2e-tests writes API and end-to-end coverage; the Test Architect module goes deeper | Kiro — Built-in test generation: YesProperty-based testing in the IDE, aimed at the edge cases unit tests miss | Agent Skills — Built-in test generation: YesTest-driven development and browser-testing skills |
| Event hooksSomething firing on save or on commit without you asking. | Spec Kit — Event hooks: No | OpenSpec — Event hooks: No | BMAD Method — Event hooks: PartialAn on_complete hook fires when a workflow finishes and can chain other skills. Nothing fires on save or commit | Kiro — Event hooks: YesHooks fire on file save, tool use, or task completion | Agent Skills — Event hooks: PartialThe Claude Code plugin ships a session-start hook; nothing fires on save or commit |
| Native MCP integration | Spec Kit — Native MCP integration: PartialWhatever your agent already supports | OpenSpec — Native MCP integration: PartialWhatever your agent already supports | BMAD Method — Native MCP integration: PartialWhatever your agent already supports | Kiro — Native MCP integration: YesMCP, AGENTS.md and agent skills, with .kiro/ shared across every surface | Agent Skills — Native MCP integration: PartialWhatever your agent already supports |
| Custom agents and workflows | Spec Kit — Custom agents and workflows: PartialExtensions and presets layer over the core templates | OpenSpec — Custom agents and workflows: PartialCustom workflow schemas via openspec schema init and fork; no custom personas | BMAD Method — Custom agents and workflows: YesThe Builder module makes new personas and workflows first-class, and _bmad/custom/ overrides any shipped skill. A personal file wins over the team file, and the team file wins over the default | Kiro — Custom agents and workflows: YesCustom agents in .kiro/agents/, in the IDE and CLI | Agent Skills — Custom agents and workflows: YesSkills are plain Markdown; writing your own is the intended path |
| Tasks into tracker issues | Spec Kit — Tasks into tracker issues: Yestaskstoissues opens GitHub issues from the task list; community extensions mirror specs into Jira | OpenSpec — Tasks into tracker issues: NoNothing in the box. Change folders are plain directories you can name after tickets | BMAD Method — Tasks into tracker issues: PartialNothing built in, but an on_complete hook can create tickets through your MCP tools. sprint-status.yaml is a local record that never syncs with your backlog | Kiro — Tasks into tracker issues: No | Agent Skills — Tasks into tracker issues: N/A |
| Unattended executionWhether it can work through a queue of stories without a human between each one. | Spec Kit — Unattended execution: NoImplement works one feature's task list; nothing drives a backlog | OpenSpec — Unattended execution: NoApply runs one change at a time, because reviewing before code is the point | BMAD Method — Unattended execution: Yesbmad-build-auto is the unattended worker for one story. BMad Loop, a separate early-beta Python orchestrator, runs a whole epic | Kiro — Unattended execution: YesAn autonomous mode in the web agent, plus Crew for scheduled background work | Agent Skills — Unattended execution: PartialBuild has an auto mode that implements every task in one approved pass; nothing spans a backlog |
Adopting it
What you install, what it costs, who maintains it, and how much of your existing setup you have to give up.
| Criterion | Spec KitGitHub | OpenSpecFission AI | BMAD MethodBMad Code | KiroAWS | Agent SkillsAddy Osmani |
|---|---|---|---|---|---|
| Install | uv tool install specify-cli | npm i -g @fission-ai/openspec | npx bmad-method install | Download the IDE or CLI, or use the web and mobile apps | npx skills add addyosmani/agent-skills |
| Runs in the editor you already use | Spec Kit — Runs in the editor you already use: Yes | OpenSpec — Runs in the editor you already use: Yes | BMAD Method — Runs in the editor you already use: YesThe installer writes into the tool you pick | Kiro — Runs in the editor you already use: NoKiro is the editor | Agent Skills — Runs in the editor you already use: Yes |
| Agents and editors supported | 38 integrations | 30+ | Most major coding agents, chosen at install | Kiro's own agent only | 70+ |
| Open source | Spec Kit — Open source: YesMIT | OpenSpec — Open source: YesMIT | BMAD Method — Open source: YesMIT | Kiro — Open source: NoProprietary. The IDE builds on Code OSS, and Kiro Crew is open source | Agent Skills — Open source: YesMIT |
| Cost | Free. You pay for your own agent | Free. You pay for your own agent | Free. You pay for your own agent | Free tier, then credit-based plans | Free. You pay for your own agent |
| Model choice | Whatever your agent runs | Whatever your agent runs | Whatever your agent runs | A curated set inside Kiro: Claude models plus an Auto router | Whatever your agent runs |
| Maintained byWorth asking about anything your team's process will depend on. | GitHub | Fission AI, a small team | BMad Code, with a large and fast-moving community | AWS | Addy Osmani, with community contributions |
Questions people ask first
- Which spec-driven development framework should I use?
- It depends on the work you do most. If you mostly modify an existing codebase in many small changes, or you are starting an open source library, use OpenSpec. If you build new features in a GitHub-centric team, use Spec Kit. If your work swings between one-line fixes and multi-epic projects, and you want to customise the workflow rather than fork it, use BMAD Method. If you want one vendor to supply the editor, the agent and the workflow together, use Kiro.
- What is the difference between Spec Kit and OpenSpec?
- Spec Kit organises around features: each one gets its own numbered folder with a spec, a plan and a task list, and a project-wide constitution sits above them all. OpenSpec organises around changes. Each change is written as a delta with ADDED, MODIFIED and REMOVED requirements, and merges back into a spec library that ends up describing what the system does today. That makes OpenSpec the stronger pick for a long-lived codebase. It also works well for a new open source library, because a contributor who has never used spec-driven development can follow one change folder without learning a whole method first.
- Is Agent Skills an alternative to Spec Kit or OpenSpec?
- No. It works alongside them. Agent Skills is a collection of skill files that encode senior-engineer practice (writing a spec, breaking work down, test-driven development, code review, security hardening), each one written as a process the agent follows. It has no opinion about where your specs live or what your change folder is called, so it layers on top of any of the other four. If your problem is an agent that skips the boring parts, install this now, without waiting to pick a framework.
- Is BMAD Method overkill for a small team?
- Usually not. BMAD sizes the process to the work. Nothing is mandatory, and a small clear change goes straight to bmad-build with one sentence and no spec, no PRD and no persona. The documents (a PRD, UX notes, an architecture spine) only appear when the work is large enough to need several build sessions to agree with each other. The surface area is large, though: eight core skills, sixteen delivery skills, five personas and four optional modules. For a small team, the cost is learning which parts to ignore. For obvious edits, BMAD's own docs tell you to skip the framework and just ask the agent.
- Can I use more than one of these at once?
- Two spec frameworks in one repo fight over the same folders and the same commands, so pick one of Spec Kit, OpenSpec, BMAD or Kiro. Agent Skills is the exception. It is plain Markdown that loads on demand and has no folder layout of its own, so it works with whichever of the four you pick.
- Do these frameworks work on an existing codebase?
- All of them can, but they get there differently. OpenSpec is designed for it and needs nothing special. BMAD lets you point bmad-build straight at a change and follow the conventions it finds; bmad-project-context can write a verified block in your AGENTS.md first, but it is optional. Kiro's design stage reads your code before it proposes anything. Agent Skills has nothing to bootstrap at all. Spec Kit is the weakest here: its specs are scoped per feature, and beyond the converge command, reverse-engineering the surrounding system is left to you.
- Are spec-driven development frameworks free?
- Spec Kit, OpenSpec, BMAD Method and Agent Skills are all MIT-licensed and free to install; the only cost is the AI agent you already pay for. Kiro is a proprietary AWS product with a free tier and credit-based paid plans on top of it.
- How hard is it to switch frameworks later?
- The artifacts are Markdown in shallow folders, so moving a spec library to a different framework takes about an afternoon of reformatting. The habit of writing the spec before the code comes with you.
Chapter 7 of AI-Native Software Engineering works through each of these in full, with the file layouts, the command vocabularies and the failure modes. The spec-driven development essay covers the loop underneath all of them, and the roadmap is the seven-day path if you would rather practise than read.