SDD Frameworks Deep Dive: GitHub Spec Kit, OpenSpec, and BMAD-METHOD Compared

Foundation reading: Spec-Driven Development with Agentic AI · Alternative Paradigms in AI-Assisted Engineering · Orchestrating AI Agents in CI/CD Pipelines

The SDD ecosystem has produced three frameworks that approach the same fundamental problem — keeping AI agents aligned with your architectural intent — from three very different angles. GitHub Spec Kit treats your project like a constitutional document. OpenSpec treats every change as a proposal that needs approval before a single line of code gets touched. BMAD-METHOD treats your entire development organization as a multi-agent squad to orchestrate.

This article is not a quick comparison table. It is a research-oriented analysis of what each framework actually does under the hood, where they shine, where they fall short, and how a solo developer or small indie team might think about choosing between them.

---

The Shared Problem: Context Collapse in Agentic AI

Before dissecting each framework, it helps to name the exact problem they all solve.

When you instruct an AI coding agent to implement a feature, it generates code that is correct in a narrow, syntactic sense but often wrong in a broader architectural sense. It uses the wrong abstraction layer. It ignores a performance constraint you documented six months ago. It reintroduces a pattern you explicitly banned.

The root cause is context collapse: the agent has no durable, structured access to your accumulated architectural decisions. Chat history is ephemeral. Code comments are scattered. A README is a marketing document, not a machine-readable contract.

All three frameworks attempt to solve this by externalizing your architectural intent into persistent, version-controlled artifacts that agents can query before generating anything. They differ radically in how they structure those artifacts and when they enforce them.

---

1. GitHub Spec Kit — The Constitutional Approach

Core Philosophy

Spec Kit was developed internally by GitHub while building Copilot features and open-sourced under MIT in late 2025. Its central metaphor is legal: your project has a constitution, and every feature spec is legislation that must comply with it.

The framework is not primarily a workflow tool. It is a context-management system for AI agents. The constitution file (.specify/memory/constitution.md) is the artifact the agent is expected to read before taking any action.

Anatomy of a Spec Kit Project

.specify/
├── memory/
│   └── constitution.md        # The "north star" — always loaded as context
├── specs/
│   └── feature-auth.md        # Feature-level specification
├── plans/
│   └── plan-auth.md           # Implementation plan tied to spec
└── tasks/
    └── tasks-auth.md          # Atomic task list auto-generated from plan

The constitution encodes:

• Engineering standards (test coverage minimums, code review requirements)
• Architecture constraints (chosen patterns, forbidden anti-patterns)
• Technology mandates (approved libraries, forbidden dependencies)
• Security and compliance rules
• Operational requirements (observability, deployment protocols)

The four-phase workflow (/speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks) is deliberately gated at each phase: an AI agent cannot advance to implementation without human approval of the plan. This is the framework’s most important design decision. It keeps humans as the final arbiters of architectural intent while delegating mechanical execution to agents.

Strengths

For indie developers and small teams, Spec Kit’s constitution model is genuinely powerful. Once you invest the time to write a thorough constitution — which typically takes a few hours for a well-understood project — the AI agent gains a persistent “memory” of your preferences that survives across sessions. You no longer repeat yourself. The agent already knows you prefer functional composition over class hierarchies, or that you have a strict no-any TypeScript policy, or that every database operation must be wrapped in a retry mechanism.

The phase gates also enforce discipline in a way that’s surprisingly hard to replicate manually. When the agent cannot proceed past “plan” without your approval, you are forced to read and critique the plan before ten hours of implementation go in a direction you didn’t intend.

Weaknesses

The constitution model assumes greenfield clarity — that you already know your architecture well enough to write it down. For brownfield projects, or for projects in active exploration, the constitution quickly becomes stale or so hedged with caveats that it loses its authority.

The four-phase gate is also a bottleneck. For small, clearly scoped changes (a bug fix, a minor refactor), the full specify → plan → tasks ceremony is significant overhead. Spec Kit does not have a “lightweight mode” for trivial changes.

Best Fit

Projects with stable, well-understood architectures. Teams (or solo devs) who have already committed to a specific tech stack and set of patterns. GitHub-native workflows with Copilot. Any situation where the cost of an AI agent drifting from your architecture is high.

---

2. OpenSpec — The Change-Proposal Approach

Core Philosophy

OpenSpec, maintained by Fission-AI, takes a different starting point: it assumes you are modifying an existing system more often than you are building from scratch. Its central metaphor is not constitutional law but change management: every modification to the codebase begins as a formal proposal.

The spec is not a persistent project-level document but a per-change artifact that lives and dies with the change it describes.

Anatomy of an OpenSpec Change

openspec/
├── main/
│   └── specs/                 # Live, canonical project specs
│       ├── features.md
│       └── scenarios.md
└── changes/
    └── ch-0042-add-oauth/     # Isolated change directory
        ├── proposal.md        # Why / What / Scope
        ├── specs/             # Deltas: additions, modifications, removals
        │   └── oauth-spec.md
        ├── tasks.md           # Atomic, verifiable checklist
        └── design.md          # Optional architecture decisions

The specs/ directory under a change contains spec deltas — documents that explicitly mark each requirement as an addition, modification, or removal relative to the main spec. This is the framework’s key innovation: it models change rather than state.

The Validation Step

OpenSpec ships a CLI (openspec validate) that checks spec-task alignment before implementation begins. The validator confirms that every task traces back to a spec requirement and that no task is an orphan without documented intent. This catches mismatches between what was proposed and what was planned before code is written.

npx openspec init
npx openspec new-change "add-oauth-login"
# Populate proposal.md, specs/, and tasks.md
npx openspec validate   # Ensures spec ↔ task coherence
# Implement
npx openspec archive    # Merges deltas into main specs

Brownfield-First Design

OpenSpec’s most distinctive quality is that it was designed for the messy reality of existing codebases. The archive command is the mechanism: when a change is tested and merged, the spec deltas are folded back into the main main/specs/ directory. Over time, even a codebase that started with no specs accumulates a full, accurate spec by incremental contribution. This is retroactive spec building — you do not need to write the whole spec before starting; each change contributes its piece.

This makes OpenSpec uniquely suited to the common indie dev scenario: a project you have been building for two years with no formal documentation, where you want to start introducing AI-assisted development without a total rewrite of your documentation first.

Strengths

• Brownfield friendliness is the killer feature. You can start with an empty main/specs/ and build it incrementally.
• Change isolation: because each change is a self-contained directory, AI agents have exactly the context they need and nothing more. This reduces noise and hallucination from over-broad context loading.
• Traceability by design: the proposal → spec delta → task → code chain creates a natural audit trail. You can always answer “why does this code exist?” by looking at the archived change.
• Tool-agnostic: all artifacts are plain Markdown. Works with any AI agent that can read files.

Weaknesses

• The per-change ceremony is lighter than Spec Kit’s but still requires discipline. For rapid prototyping or truly exploratory work, even a short proposal.md can feel like friction.
• There is no equivalent of Spec Kit’s constitution — no persistent project-level document that the agent consults before acting. OpenSpec’s main specs grow incrementally but are not designed to be “loaded as context” in the same pre-emptive way a constitution is.
• The CLI tooling is newer and less mature than Spec Kit’s Copilot integration.

Best Fit

Evolving projects, legacy modernization, brownfield scenarios. Solo developers who want to incrementally introduce rigor without writing a full spec upfront. Projects where changes are small and frequent, and where change-level traceability matters more than project-level constitution.

---

3. BMAD-METHOD — The Multi-Agent Orchestration Approach

Core Philosophy

BMAD (Breakthrough Method for Agile AI-Driven Development) is the most ambitious of the three frameworks. Where Spec Kit and OpenSpec are primarily specification tools, BMAD is an agent orchestration system that happens to use specifications as its inter-agent communication protocol.

The central metaphor is organizational: your development project is run by a team of specialized AI agents, each owning a defined role in the agile lifecycle. The human developer is not the implementer; they are the product owner and final approver.

The Agent Squad

BMAD ships with a pre-built squad of over 20 agents defined as version-controlled Markdown and YAML files:

Agent	Role	Key Artifact
Analyst	Requirements gathering, market research	PRD (Product Requirements Doc)
Architect	System design, ADRs	Architecture doc
PM	Sprint planning, milestones	Project brief
Scrum Master	Story creation, sprint management	User stories
Developer	Code generation	Implementation
QA	Testing strategy, test cases	Test plan
UX Expert	User flows, UI specs	Design docs
Librarian	Documentation, knowledge management	Docs index

Each agent is defined as a YAML file specifying its persona, expertise, available commands, memory management strategy, and inter-agent handoff protocols. This is the Agent-as-Code principle: an agent is not a configuration in a dashboard but a version-controlled artifact that lives in your repo.

The Lifecycle

Product Vision
     ↓
[Analyst Agent] → PRD.md
     ↓
[Architect Agent] → architecture.md, ADRs
     ↓
[PM Agent] → project-brief.md, milestones
     ↓
[Scrum Master] → user-stories/sprint-N/
     ↓
[Developer Agent] → src/ (feature implementation)
     ↓
[QA Agent] → tests/, quality-report.md
     ↓
[Release Agent] → deployment

At each handoff, the receiving agent is given the artifacts produced by the prior agent as context. The architecture doc informs the developer agent. The PRD informs the QA agent’s acceptance criteria. Context is preserved across agents, not just within a single agent session.

Strengths

• End-to-end orchestration: BMAD is the only framework that models the full development lifecycle, from requirements gathering to deployment. The others focus on the specification-to-implementation phase.
• Persistent organizational knowledge: because agents, their personas, and their knowledge are defined as files in the repo, the “team’s” accumulated context survives session resets and team turnover.
• Adaptable to project scale: BMAD includes lighter-weight “IDE mode” configurations for solo devs and full enterprise configurations for large teams. The same methodology scales.
• Excellent for complex projects: when a feature requires coordination between architecture decisions, UI design, and backend implementation, BMAD’s role separation prevents the cognitive context collapse that happens when one agent tries to be all things.

Weaknesses

• High ceremony for small changes: BMAD’s full lifecycle is significant overhead for a bug fix or a small feature. The framework is most valuable at the architecture and planning stages, not at the maintenance stage.
• Steep learning curve: with 20+ agents, each with their own YAML configuration and command set, the initial setup is non-trivial. The documentation is comprehensive but dense.
• Requires commitment: switching to BMAD mid-project requires migrating your existing documentation into BMAD’s artifact structure. This is feasible but takes deliberate effort.
• Less spec-centric: because BMAD’s value is in agent coordination, the individual spec artifacts (PRD, architecture doc) are less rigorously structured than Spec Kit’s phase-gated specs or OpenSpec’s formal deltas.

Best Fit

Large, complex projects where the full development lifecycle benefits from agent specialization. Solo developers who want to simulate a full development team using AI agents. Projects starting from scratch (greenfield), where BMAD’s planning agents can establish the architecture before a single line of code is written.

---

Comparative Analysis

By Project Phase

Phase	Best Framework	Rationale
New project, architecture definition	BMAD	Analyst + Architect agents produce comprehensive upfront planning
Greenfield feature development	Spec Kit	Phase gates enforce discipline and spec quality
Brownfield change to existing system	OpenSpec	Change-proposal model designed for modification, not creation
Legacy modernization	OpenSpec	Incremental spec building via archive mechanism
Large team coordination	BMAD	Agent roles mirror agile team structure
Solo dev, high-quality specs	Spec Kit	Constitution model provides persistent context across sessions

By Specification Model

Framework	Spec Scope	Spec Lifetime	Enforcement
Spec Kit	Project (constitution) + Feature	Permanent	Phase gates, Copilot integration
OpenSpec	Per-change delta	Change lifecycle, then archived	openspec validate CLI
BMAD	Per-role artifact (PRD, arch doc, etc.)	Sprint / milestone	Agent handoff protocols

By AI Tool Integration

• Spec Kit: Deep GitHub Copilot integration via slash commands. The /speckit.* commands are first-class Copilot features. Less friction for GitHub-native teams.
• OpenSpec: Tool-agnostic Markdown-based workflow. Works with any AI agent (Claude Code, Cursor, Copilot, Codex). Requires manual file management.
• BMAD: Designed for orchestration across multiple AI platforms. The BMAD installer generates AGENTS.md and agent YAML files that work with Claude Code, Cursor, and similar tools. IDE-mode is optimized for Cursor.

Combining the Frameworks

These frameworks are not mutually exclusive. A mature SDD workflow might use:

1. BMAD for project inception and architecture planning (leveraging the Analyst and Architect agents to produce PRD and ADRs)
2. Spec Kit for feature development (converting BMAD’s architecture doc into a constitution, then using Spec Kit’s phase gates for individual features)
3. OpenSpec for maintenance and brownfield changes (once the project is established, using change proposals for all modifications)

This layered approach is not hypothetical — several teams have documented using BMAD for planning while adopting OpenSpec or Spec Kit for implementation-phase discipline.

---

Practical Recommendation for Indie Developers

If you are a solo developer maintaining one or more personal projects:

Start with OpenSpec. The brownfield-first design means you can introduce spec discipline into existing projects without a documentation rewrite. The change-proposal model matches the natural rhythm of indie development: you have an idea, you scope it, you implement it. OpenSpec just adds a small formalization layer to the scoping phase.

Add Spec Kit’s constitution concept once you have built up enough change history to articulate your architecture. Write a constitution from your accumulated OpenSpec changes — it will be more accurate and specific than anything written speculatively upfront.

Explore BMAD when tackling a significant new project from scratch or when a feature is complex enough to genuinely benefit from separating architecture design from implementation.

The common thread: the value of SDD is proportional to the durability of the artifacts it produces. Ephemeral specs written to satisfy a process and then discarded add ceremony without benefit. Specs that agents actually read, that survive session resets, and that evolve alongside the code — those are the artifacts worth writing.

---

References and Further Reading

• GitHub Spec Kit Repository
• Spec Kit Constitution Command — DeepWiki
• Diving Into Spec-Driven Development With GitHub Spec Kit — Microsoft Developer Blog
• Extending Spec Kit for Constitution-Based PR Reviews — Mark Hazleton
• OpenSpec Repository — Fission-AI
• OpenSpec Official Documentation
• OpenSpec Deep Dive: Architecture & Practice — Redreamality
• BMAD-METHOD Repository
• BMAD-METHOD Official Docs
• BMAD-METHOD Guide: Breakthrough Agile AI-Driven Development — Redreamality
• Agent Orchestration in BMAD — DeepWiki
• Multi-Agent Orchestration: BMAD, Claude Flow, and Gas Town — re:cinq
• Agent-as-Code: BMAD-METHOD — DEV Community