Spec Kit vs OpenSpec vs BMAD: what each leaves out

Published 18 October 2026

Spec Kit, OpenSpec and BMAD are spec-driven development tools: each has an AI coding agent write down what it will build before it builds it. They differ in how much process they wrap around that. Spec Kit takes each feature through a fixed pipeline: specify, plan, tasks, implement. OpenSpec keeps one living spec and changes it a delta at a time. BMAD brings in agent roles — product, architecture, UX, testing — and sizes the planning to the change. All three keep the spec as markdown in the repository, written with the agent and reviewed by the developer running it. That is where the gaps they share come from.

Spec Kit, OpenSpec and BMAD at a glance

Stars as of 18 October 2026. To install: uv tool install specify-cli, npm install -g @fission-ai/openspec, or npx bmad-method install.

Spec Kit vs OpenSpec

The difference is what a spec is. In Spec Kit, a spec belongs to a feature: each feature gets its own folder with a spec, a plan and tasks, and you can add gates between the steps — clarification, checklists, a consistency analysis. In OpenSpec, a spec describes the system as it is: openspec/specs/ holds “the current agreed-upon behavior” (OpenSpec concepts), and each change is a proposal with a delta — added, modified, removed — that merges in when the change is archived.

That makes OpenSpec lighter and Spec Kit more thorough, and users split along that line:

I love openspec’s lightweight, process agnostic approach. Speckit generates way too much boilerplate to review.

— r/ClaudeCode, December 2025

SpecKit is about making spec changes as safe and explicit as possible. OpenSpec is a very lightweight framework by comparison.

— Hacker News, September 2026

OpenSpec’s own README calls Spec Kit “Thorough but heavyweight. Rigid phase gates, lots of Markdown, Python setup” — the view of a competitor. Others see little difference: “I think basically these are the same tools” (Hacker News). Some combine them: one developer loves “speckit’s constitution concept and how it construct prd, but prefer the simplicity of openspec for actual spec creation” (r/ClaudeCode).

On an existing codebase, OpenSpec’s change-by-change model fits most naturally; Spec Kit now has a guide for it too. See spec-driven development on an existing codebase.

Spec Kit vs BMAD, and OpenSpec vs BMAD

BMAD is less a spec format than a method: it brings in product, architecture, UX, development and testing perspectives as agent roles, and produces briefs, a PRD, architecture and epics before the build. That depth is what users noticed first. One commenter summed up all three:

I found bmad to cause massive overscoping.

Openspec under defines what you’re trying to build.

Spec kit has been rock solid for me every time I use it.

— r/ClaudeCode, December 2025

Another, using BMAD for an important personal project: “while the idea behind it is great, it feels far too heavy to use” (r/ClaudeCode). Those comments are from December 2025. BMAD’s current README says the process sizes itself: “Small changes go straight to build. Complex work gets the depth it needs.”

Where Superpowers, Kiro and GSD fit

OpenSpec vs Superpowers is a common question, and the two are not really alternatives. Superpowers is about how the agent works: once “it’s teased a spec out of the conversation”, it shows it to you “in chunks short enough to actually read and digest”, then plans, tests first and reviews between tasks. OpenSpec is about what the spec says over time. OpenSpec’s second most-supported request, with 50 reactions, came from someone running both and asked to ship OpenSpec as a Superpowers skill pack (OpenSpec #780).

Spec Kit vs Kiro: Kiro is a product with specs built in; Spec Kit, OpenSpec and BMAD are added to the coding agent you already use. Kiro adds steering files that describe the product, the tech stack and the project structure to the agent.

GSD is mostly about context: research, planning and execution run in fresh subagents, so the main session stays lean.

The more process a tool has, the more people find it too much. One developer who uses OpenSpec “to negotiate requirements before the handoff”: “You could also use GSD2 or Amazon’s Kiro, or Spec Kit but I find they have too many stages and waste tokens” (Hacker News, April 2026). Another: “I think these type of systems (gsd/superpowers) are way too opinionated” (Hacker News).

What users ask each tool for

The most-supported requests about specs, from each project’s issue tracker (October 2026). Closed does not always mean built.

Almost none of it is about writing the first spec. It is about what happens next: changing a spec, fixing what was built from it, deriving one from existing code, and keeping many of them in order.

What all of them leave out

A reader who is not a developer. In every one of these tools the spec is markdown in the repository, written for the agent and the developer running it. A client, a product owner or a compliance reviewer cannot comfortably read or approve it there — “Non-programmers are not used to working with Git” (Hacker News). See who reviews the spec.

A sign-off on a version. Approval is the developer moving to the next step, or a merged pull request — not a recorded sign-off, by the people who asked for the work, on one version of the spec.

What a change does to the rest of the spec. Checks run inside a change — Spec Kit’s analysis compares one feature’s spec, plan and tasks. Finding the other specs a change affects is left to the developer and the agent:

A new feature can easily affect 2 or 3 specs. Do you update them manually?

— Hacker News, February 2026

Drift after the change. Specs and code part ways once the work is merged. A Kiro user, asking for the code’s commit to be recorded with each spec:

The git history of the spec only tells you when the spec changed — not whether the source code it references has diverged since then.

— Kiro #9435, June 2026

Drifting specs were one of the three complaints we found most often about these tools (what 20,000 comments say); see what spec drift is.

A team that does not all use the same tool. “If you’ve got devs: not using any structured workflow, or using a variety (speckit, openspec, superpowers, their own) it’s going to be hard to control the quality of the development process itself and its outputs” (Hacker News, August 2026).

Which one should you use?

From the tools’ own documentation and what users report — not from a benchmark of ours:

• OpenSpec, if you work on an existing codebase in small changes and want one spec that describes the system as it is.
• Spec Kit, if you want each feature taken through research, a plan and tasks, with checks between the steps, and you do not mind more to review.
• BMAD, if the work needs product and architecture thinking before any code, from several perspectives.
• Superpowers, if your problem is how the agent works — tests first, review between tasks — more than what the spec says. Many run it with OpenSpec or Spec Kit.
• Kiro, if you want specs built into the editor.
• GSD, if long sessions lose the thread.
• None of them, for a one-off change by one developer. “Most coding agents already have a plan mode and a task list” (Marmelab).

How to set each of them up in Claude Code, and the workflow without any of them: spec-driven development with Claude Code.

Where Specroot fits

These gaps are the problem Specroot works on: one versioned specification for everyone who has to agree with it, not only for the coding agent. Specroot for teams using AI coding agents.