Resources / Compare
Spec Kit vs OpenSpec vs BMAD vs Kiro vs Agent Skills.
Five ways to put a specification in front of a coding agent, compared on the things that decide which one your team keeps using: how much process runs before code gets written, where the review checkpoints land, what happens on an existing codebase, and who is left holding the maintenance.
- 5 tools
- 27 criteria
- Sources checked 16 September 2026
The lineup
- 01GitHub ↗
Spec Kit
The middle ground. A constitution at the project root, then a spec, a plan and a task list for every feature.
- Best for
- Greenfield features in teams that already live in GitHub, and mixed toolchains that need one shared vocabulary across thirty different agents.
- Think twice if
- Most of your day is one-file fixes to legacy code, where four commands cost more than they save.
OpenSpec
The light option. One change folder per modification, with delta specs that merge back into a library describing what the system does today.
- Best for
- Existing codebases that take many small changes, where the spec library should grow with the code instead of going stale next to it.
- Think twice if
- You are designing a new product from scratch, or you want enforceable gates between the spec and the technical design.
BMAD Method
The adjustable option. Everything funnels into one build session; larger work wraps that same unit in a spec, then a PRD and an architecture spine, and repeats it.
- Best for
- Teams who want one tool for both a one-line fix and a twenty-epic platform, and who will use the extension points — skill overrides, completion hooks and custom modules.
- Think twice if
- You want a small surface to learn. Thirty-odd skills, five personas and four optional modules is a lot to keep in your head for one-file changes.
- 04AWS ↗
Kiro
The product. The spec workflow, the agent, the hooks and MCP all live in one IDE, CLI, web and mobile app rather than in a set of Markdown prompt files.
- Best for
- Teams happy for a single vendor to supply the editor, the agent, the spec workflow, the hooks and the billing.
- Think twice if
- You have standardised on Cursor or VS Code with Copilot, or you need full model choice across providers.
Agent Skills
The layer, not the framework. Two dozen skills that encode senior-engineer practice and load on demand, on top of whatever spec workflow you already run.
- Best for
- Adding review, testing and security discipline to an existing workflow, or getting most of the day-to-day value without adopting a framework at all.
- Think twice if
- What your team is missing is a shared spec layout and gates between spec and code. Skills give you neither.
The comparison
27 criteria in four groups. Uncheck a column to narrow the table down to the two or three you are actually 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 just 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, three optional commands on top | Light — propose, apply, archive | Whatever you ask for — nothing is mandatory. One sentence to build, or a full document suite for a multi-epic project | Medium — requirements, design and tasks approved in turn; 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 — but nothing forces an order, 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 — 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
The parts that are not about writing the spec: review, tests, automation, and the seams where the tool meets 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 — personal file over team file over 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 — 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
The practical questions: 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 |
Four questions that settle it
The list is short, but the decision feels heavy the first time. Four questions carry most of the signal; the rest is preference.
- 01
Is your work mostly greenfield or mostly brownfield?
This one split removes most of the ambiguity. Designing a product from scratch, with several engineers and a long planning horizon, puts you in Spec Kit or BMAD territory. Modifying an existing codebase through many small changes puts you in OpenSpec territory, because its delta specs are the only mechanic here that turns a stream of changes into a description of what the system does today. BMAD sits in both camps, since its build session reads the conventions already in your code, but it is the only one of the three that gives you no compounding spec library at the end.
- 02
How much ceremony will your team actually run?
Not how much it should run. The test is whether the artifacts would survive your next review week. Spec Kit and Kiro decide this for you: their stages are named, and you feel it when you skip one. BMAD does not decide — nothing in it is mandatory, so the honest question there is whether your team will reach for the planning skills at all, or quietly run every change through a single build session forever. If you can picture a PRD and an architecture spine going stale in seven days, you want OpenSpec’s footprint — or Agent Skills on its own, which asks for no artifacts at all.
- 03
What does your editor and agent mix look like today?
Spec Kit ships thirty-eight integrations, OpenSpec thirty-plus, and Agent Skills installs into more than seventy, which suits a team that never standardised. BMAD covers most major agents too, chosen at install. Kiro is the opposite bet: it is the right fit only if your team is willing to move into its IDE, and the wrong one if you have already settled on Cursor or VS Code with Copilot.
- 04
Who maintains it, and what happens when it changes?
The question people skip. Spec Kit is backed by GitHub, which signals credibility without guaranteeing it. OpenSpec is a small team — two core maintainers at the last check. BMAD has a large community and moves fast enough that a version upgrade can shift agent definitions under your repo. Kiro is an AWS product, so it lives and dies on AWS’s roadmap. Read the changelogs, and keep your team’s process out of the direct path of anything that rewrites itself twice a year.
Questions people ask first
- Which spec-driven development framework should I use?
- Start from your work, not from the feature list. If you mostly modify an existing codebase in many small changes, 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. Any of them, used with discipline, beats two more weeks of comparison.
- 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 to a system that already exists: 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. Spec Kit is the better fit for greenfield work; OpenSpec is the better fit for a long-lived codebase.
- Is Agent Skills an alternative to Spec Kit or OpenSpec?
- No, and that is why it is worth knowing about. 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 — written as processes an agent follows rather than documents it reads. 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 the gap you feel is not "we have no spec process" but "our agent skips the boring parts", this is the thing to install, and you do not have to choose a framework first.
- Is BMAD Method overkill for a small team?
- Less than its reputation suggests. 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. What is genuinely large is the surface area: eight core skills, sixteen delivery skills, five personas and four optional modules. So the real cost for a small team is learning what to ignore, not ceremony you are forced to run. For truly 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 fires on demand rather than a competing file layout, so it composes with whichever of the four you land on.
- 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?
- Lower than it feels. The artifacts are Markdown, the file layouts are shallow, and the real asset is the habit of writing the spec before the code. Moving a spec library between frameworks is an afternoon of reformatting. Spending two weeks choosing is the expensive option.
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.