# Spec Kit vs OpenSpec vs BMAD vs Kiro vs Agent Skills

> A side-by-side comparison of the spec-driven development frameworks across 25 criteria: workflow shape, review gates, brownfield support, cost and lock-in.

- **Source:** https://ainativesoftware.engineering/compare
- **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book

A side-by-side comparison of 5 spec-driven development frameworks across 25 criteria: workflow shape, review gates, brownfield support, cost and lock-in.

- **Frameworks:** Spec Kit, OpenSpec, BMAD Method, Kiro, Agent Skills
- **Criteria:** 25
- **Verified against source:** 10 August 2026

## The frameworks

### Spec Kit ([GitHub](https://github.com/github/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.
- **Avoid if:** Most of your day is one-file fixes to legacy code, where four commands cost more than they save.

### OpenSpec ([Fission AI](https://github.com/Fission-AI/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.
- **Avoid if:** You are designing a new product from scratch, or you want enforceable gates between the spec and the technical design.

### BMAD Method ([BMad Code](https://github.com/bmad-code-org/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.
- **Avoid if:** You are one developer shipping small changes and have no appetite for running a simulated product team.

### Kiro ([AWS](https://kiro.dev/))

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.
- **Avoid if:** You have standardised on Cursor or VS Code with Copilot, or you need full model choice across providers.

### Agent Skills ([Addy Osmani](https://github.com/addyosmani/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.
- **Avoid if:** What your team is missing is a shared spec layout and gates between spec and code. Skills give you neither.

## The comparison

### 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.

#### Unit of work

The thing you point it at.

- **Spec Kit:** One feature, on its own branch
- **OpenSpec:** One change to an existing system
- **BMAD Method:** One product, then epics, then stories — small changes go straight to build
- **Kiro:** One feature, or one bug
- **Agent Skills:** One task the agent is about to start

#### What one unit produces

The artifacts a human has to read and approve.

- **Spec Kit:** A spec, a plan and a task list, plus contracts and research notes
- **OpenSpec:** A proposal, a delta spec, a design note and a task list
- **BMAD Method:** A brief, a PRD, an architecture document, epics, stories and sprint status
- **Kiro:** requirements.md (or bugfix.md for a bug), design.md and tasks.md
- **Agent Skills:** 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

- **Spec Kit:** `specs/<nnn-feature>/` · `.specify/memory/constitution.md`
- **OpenSpec:** `openspec/specs/` · `openspec/changes/` · `openspec/changes/archive/`
- **BMAD Method:** `_bmad-output/planning-artifacts/` · `_bmad-output/specs/spec-<slug>/` The default output folder, chosen at install
- **Kiro:** `.kiro/specs/<feature>/` · `.kiro/steering/`
- **Agent Skills:** No artifact folder of its own. The skills install into .claude/skills/ — or the matching folder for whichever of the 70+ agents you run

#### Ceremony

How much process runs before any code gets written.

- **Spec Kit:** Medium — four named commands, two more if you want them
- **OpenSpec:** Light — propose, apply, archive
- **BMAD Method:** Heavy — a full document suite, with a light track for small work
- **Kiro:** Medium — requirements, design and tasks approved in turn; a Quick Spec path skips the gates
- **Agent Skills:** Light — a skill loads only when the task calls for it

#### Named agent personas

Separate agents with their own scope, handing artifacts to each other.

- **Spec Kit:** **No** One agent, many commands
- **OpenSpec:** **No** Single-agent by design
- **BMAD Method:** **Yes** Analyst, Product Manager, Architect, Developer, UX Designer
- **Kiro:** **No** One agent; independent tasks fan out in parallel
- **Agent Skills:** **Partial** A few personas ship alongside the skills, with no handoffs between them

#### Project-wide rules file

The non-negotiables every feature inherits without being told.

- **Spec Kit:** **Yes** The constitution, loaded into every spec and plan
- **OpenSpec:** **Yes** Context and rules in openspec/config.yaml, injected into every artifact
- **BMAD Method:** **Yes** A verified block in your AGENTS.md, maintained by bmad-project-context
- **Kiro:** **Yes** Steering files, shared across the IDE, CLI, web and mobile apps; AGENTS.md works too
- **Agent Skills:** **No** Composes 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.

#### Core commands

- **Spec Kit:** `/speckit.constitution` · `/speckit.specify` · `/speckit.plan` · `/speckit.tasks` · `/speckit.implement` Plus clarify, analyze, checklist, converge and taskstoissues
- **OpenSpec:** `/opsx:explore` · `/opsx:propose` · `/opsx:apply` · `/opsx:update` · `/opsx:sync` · `/opsx:archive` The expanded profile splits propose into steps and adds verify
- **BMAD Method:** `bmad-product-brief` · `bmad-prd` · `bmad-architecture` · `bmad-create-epics-and-stories` · `bmad-build` Five of the thirty-five skills in the BMad Method module
- **Kiro:** No slash commands — requirements, design and tasks are stages in the spec workflow
- **Agent Skills:** 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 design

Whether you can correct the requirements before the agent reasons about how to build them.

- **Spec Kit:** **Yes** Separate commands, so the spec exists before the plan does
- **OpenSpec:** **Partial** Propose writes the planning artifacts in one pass; the expanded profile creates them one at a time
- **BMAD Method:** **Yes** Each phase is its own workflow, run in a fresh chat
- **Kiro:** **Yes** Requirements, then design, then tasks — each approved in turn
- **Agent Skills:** **N/A** There is no pipeline to put a gate in

#### Delta specs

ADDED, MODIFIED and REMOVED markers, so a change is a diff rather than a rewrite.

- **Spec Kit:** **No**
- **OpenSpec:** **Yes** The mechanic the whole framework is built on
- **BMAD Method:** **No**
- **Kiro:** **No**
- **Agent Skills:** **No**

#### Specs compound into a system description

Whether the folder ends up describing what the system does, or only what each change did.

- **Spec Kit:** **Partial** Specs are scoped per feature and stay that way
- **OpenSpec:** **Yes** Archived deltas merge back into openspec/specs/
- **BMAD Method:** **Partial** The PRD and architecture are per project; the shared context is a block in AGENTS.md, refreshed rather than compounded
- **Kiro:** **Partial** One folder per feature, kept in version control
- **Agent Skills:** **No** Skills shape the work; they keep no library of their own

#### Brownfield entry point

A first-class way to start on a codebase that already exists.

- **Spec Kit:** **Partial** Converge assesses the codebase against the artifacts
- **OpenSpec:** **Yes** Built for it — every change is a diff against what is already there
- **BMAD Method:** **Yes** bmad-project-context discovers the context from the codebase, verified, then confirmed with you
- **Kiro:** **Yes** The design stage reads your codebase before proposing anything
- **Agent Skills:** **Yes** Nothing to bootstrap — the skills apply to whatever the repo already is

#### Mid-project scope change

A workflow for "we just learned something, let's replan".

- **Spec Kit:** **No**
- **OpenSpec:** **Yes** Update revises the planning artifacts and ripples the edit in any direction
- **BMAD Method:** **Yes** Correct-course analyzes the impact and writes a sprint change proposal
- **Kiro:** **No**
- **Agent Skills:** **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.

#### Built-in code review

- **Spec Kit:** **Partial** Cross-artifact consistency rather than a code reviewer; extensions add one
- **OpenSpec:** **No**
- **BMAD Method:** **Yes** A review workflow with independent lenses, including an adversarial one
- **Kiro:** **Partial** Validation runs tests rather than reading the diff
- **Agent Skills:** **Yes** Review, simplification and security-hardening skills, each demanding evidence

#### Built-in test generation

- **Spec Kit:** **No**
- **OpenSpec:** **No**
- **BMAD Method:** **Yes** QA runs inside the build loop; the Test Architect module goes deeper
- **Kiro:** **Yes** Property-based testing in the IDE, aimed at the edge cases unit tests miss
- **Agent Skills:** **Yes** Test-driven development and browser-testing skills

#### Event hooks

Something firing on save or on commit without you asking.

- **Spec Kit:** **No**
- **OpenSpec:** **No**
- **BMAD Method:** **No**
- **Kiro:** **Yes** Hooks fire on file save, tool use, or task completion
- **Agent Skills:** **Partial** The Claude Code plugin ships a session-start hook; nothing fires on save or commit

#### Native MCP integration

- **Spec Kit:** **Partial** Whatever your agent already supports
- **OpenSpec:** **Partial** Whatever your agent already supports
- **BMAD Method:** **Partial** Whatever your agent already supports
- **Kiro:** **Yes** MCP, AGENTS.md and agent skills, with .kiro/ shared across every surface
- **Agent Skills:** **Partial** Whatever your agent already supports

#### Custom agents and workflows

- **Spec Kit:** **Partial** Extensions and presets layer over the core templates
- **OpenSpec:** **Partial** Custom workflow schemas via openspec schema init and fork; no custom personas
- **BMAD Method:** **Yes** The Builder module makes new personas and workflows first-class
- **Kiro:** **Yes** Custom agents in .kiro/agents/, in the IDE and CLI
- **Agent Skills:** **Yes** Skills are plain Markdown; writing your own is the intended path

#### Tasks into tracker issues

- **Spec Kit:** **Yes** One command opens GitHub issues from the task list
- **OpenSpec:** **No** Nothing in the box — change folders are plain directories you can name after tickets
- **BMAD Method:** **No** Epic files hold the stories; nothing opens tickets for you
- **Kiro:** **No**
- **Agent Skills:** **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.

#### Install

- **Spec Kit:** `uv tool install specify-cli`
- **OpenSpec:** `npm i -g @fission-ai/openspec`
- **BMAD Method:** `npx bmad-method install`
- **Kiro:** Download the IDE or CLI, or use the web and mobile apps
- **Agent Skills:** `npx skills add addyosmani/agent-skills`

#### Runs in the editor you already use

- **Spec Kit:** **Yes**
- **OpenSpec:** **Yes**
- **BMAD Method:** **Yes** The installer writes into the tool you pick
- **Kiro:** **No** Kiro is the editor
- **Agent Skills:** **Yes**

#### Agents and editors supported

- **Spec Kit:** 30+
- **OpenSpec:** 30+
- **BMAD Method:** Most major coding agents, chosen at install
- **Kiro:** Kiro's own agent only
- **Agent Skills:** 70+

#### Open source

- **Spec Kit:** **Yes** MIT
- **OpenSpec:** **Yes** MIT
- **BMAD Method:** **Yes** MIT
- **Kiro:** **No** Proprietary — the IDE builds on Code OSS, and Kiro Crew is open source
- **Agent Skills:** **Yes** MIT

#### Cost

- **Spec Kit:** Free — you pay for your own agent
- **OpenSpec:** Free — you pay for your own agent
- **BMAD Method:** Free — you pay for your own agent
- **Kiro:** Free tier, then credit-based plans
- **Agent Skills:** Free — you pay for your own agent

#### Model choice

- **Spec Kit:** Whatever your agent runs
- **OpenSpec:** Whatever your agent runs
- **BMAD Method:** Whatever your agent runs
- **Kiro:** A curated set inside Kiro — Claude models plus an Auto router
- **Agent Skills:** Whatever your agent runs

#### Maintained by

Worth asking about anything your team's process will depend on.

- **Spec Kit:** GitHub
- **OpenSpec:** Fission AI — a small team
- **BMAD Method:** BMad Code, with a large and fast-moving community
- **Kiro:** AWS
- **Agent Skills:** Addy Osmani, with community contributions

## Questions people ask

### 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.

---

_AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._