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
- 25 criteria
- Sources checked 10 August 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 heavy option. Named agent personas hand a brief to a PRD to an architecture to epics and stories, with explicit handoffs between them.
- Best for
- Complex products, regulated work where the audit trail matters, and rewrites large enough that the agent needs a model of the whole system.
- Think twice if
- You are one developer shipping small changes and have no appetite for running a simulated product team.
- 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
25 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 product, then epics, then stories — small changes go straight to build | 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 brief, a PRD, an architecture document, epics, stories and sprint status | 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/planning-artifacts/
_bmad-output/specs/spec-<slug>/The default output folder, chosen at install | .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 — four named commands, two more if you want them | Light — propose, apply, archive | Heavy — a full document suite, with a light track for small work | 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: YesAnalyst, Product Manager, Architect, Developer, UX Designer | 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.implementPlus clarify, analyze, checklist, converge and taskstoissues | /opsx:explore
/opsx:propose
/opsx:apply
/opsx:update
/opsx:sync
/opsx:archiveThe expanded profile splits propose into steps and adds verify | bmad-product-brief
bmad-prd
bmad-architecture
bmad-create-epics-and-stories
bmad-buildFive of the thirty-five skills in the BMad Method module | 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 eight slash commands (/spec, /review, /test…) |
| 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: YesEach phase is its own workflow, run in a fresh chat | 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: No | 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 PRD and architecture are per project; the shared context is a block in AGENTS.md, refreshed rather than compounded | 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: Yesbmad-project-context discovers the context from the codebase, verified, then confirmed with you | 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 |
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: YesA review workflow with independent lenses, including an adversarial one | 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: YesQA runs inside the build loop; 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: No | 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 | 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: YesOne command opens GitHub issues from the task list | 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: NoEpic files hold the stories; nothing opens tickets for you | Kiro — Tasks into tracker issues: No | Agent Skills — Tasks into tracker issues: N/A |
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 | 30+ | 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.
- 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. If you can picture the team treating a PRD, an architecture document and a set of epic files as living documents, BMAD’s weight is well spent. If you can picture them going stale in seven days, you want OpenSpec’s footprint or Spec Kit’s middle ground — 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 and OpenSpec both support thirty-plus agents, and Agent Skills more than seventy, which suits a team that never standardised. BMAD covers most major agents too, with a heavier setup. 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 you plan whole products, work in a regulated industry, or are attempting a rewrite large enough that the agent needs a model of the entire system, 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?
- For a solo developer shipping small changes, yes. BMAD generates a brief, a PRD, an architecture document, epics and stories, and runs them through separate agent personas — that weight is the point, and it only pays off when the artifacts stay alive. BMAD's own answer is to right-size the process: small, clear changes go straight to bmad-build, which writes a single spec file instead of the full document suite. If most of your work fits that path, a lighter tool will cost you less.
- 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 discovers project context from the codebase — a verified block in your AGENTS.md that its downstream agents read. 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.