You Do Not Need Spec Kit If You Are Already Using BMAD

Why bmad-spec covers spec-driven development and why running both tools creates more problems than it solves

The switching problem that is not really a switching problem

Teams that discover Spec Kit while already using BMAD often frame the decision as a switch: do we stay with BMAD or move to Spec Kit? Some teams end up running both simultaneously. BMAD for planning and discovery, Spec Kit for implementation. It feels like the best of both worlds.

It is not. And understanding why requires being precise about what each tool actually does, where they genuinely overlap, and what the real cost of dual-tool artifact sprawl looks like in a working sprint.

The argument in this article is straightforward: if your team is already using BMAD, bmad-spec already gives you spec-driven development. The workflow does not have to start with a PRD. And running both BMAD and Spec Kit simultaneously creates artifact duplication, context confusion, and coordination overhead that erodes the efficiency both tools are trying to provide.

What spec-driven development actually means

Spec-driven development is a methodology where a formal specification serves as the authoritative source of truth and the primary artifact from which implementation, testing, and documentation are derived. The specification is written before implementation begins. The AI agent implements it. The spec is not a post-implementation document, it is the input that drives the implementation.

This is precisely what bmad-spec does.

bmad-spec produces a SPEC.md file with five fields: Why (the problem being solved), Capabilities (what the implementation must do), Constraints (what it must not do or must preserve), Non-goals (explicitly out of scope), and Success signal (how done is verified). This is a formal, structured specification. It is self-contained. It is written before implementation begins. bmad-dev-story (story-based path) and bmad-quick-dev (Quick Flow path) implement it.

The core mechanic of spec-driven development specification as a single source of truth, implementation derived from specification is not a Spec Kit innovation. It is what BMAD does natively with bmad-spec.

One hierarchy. One source of truth. No second spec.

The PRD is not required for all work

The most common misconception that drives teams toward Spec Kit for smaller items is the belief that BMAD requires a PRD. This belief comes from reading the BMAD workflow map top-to-bottom and assuming the phases are mandatory and sequential.

They are not. The official BMAD documentation is explicit: "Skip phases 1–3 for small, well-understood work." And: "Do I always need architecture? Only for BMad Method and Enterprise tracks. Quick Flow skips from spec to implementation."

BMAD's four phases are a menu, not a prescription. The appropriate entry point depends on what you are delivering:

New capability with compliance requirements: Start at Phase 1 (Analysis) or Phase 2 (Planning). A PRD makes sense here. The work is large, the scope is new, stakeholder alignment is required before architecture decisions are made.

Legacy feature enhancement touching multiple areas: Start at Phase 2 with bmad-spec producing a scoped SPEC.md. No PRD needed. The existing codebase is the baseline. The spec documents what changes and why.

Isolated bug fix with unclear root cause: Start at bmad-spec after RCA. The SPEC.md formalises the actual versus expected behaviour, the affected surface, and the fix boundary. No PRD, no architecture document.

Tech debt refactor: Start at bmad-spec with behavioral contract formalisation. The spec documents what the current behavior is, what must be preserved, and what changes. No PRD.

Trivial single-fix: Start at bmad-quick-dev which handles intent clarification, planning, and implementation in one workflow. Even bmad-spec is optional here.

None of these entry points require a PRD. The belief that BMAD equals PRD-first is a misreading of the workflow map. BMAD is a progressive context-building system where you start at the appropriate phase for the work at hand.

What Spec Kit adds that BMAD already has

When teams evaluate Spec Kit alongside BMAD, they typically identify three things they want:

A self-contained specification as implementation input. BMAD's bmad-spec produces exactly this. SPEC.md is a self-contained document consumed by bmad-create-story, bmad-testarch-atdd, and bmad-dev-story. It is the single source of truth for legacy enhancement, bug, tech debt, and spike tracks.

A standard for what the spec contains. BMAD's SPEC.md has a defined five-field kernel: Why, Capabilities, Constraints, Non-goals, Success signal. This is a formal structure. Spec Kit's spec.md similarly provides a structured specification format. The structures differ in naming and organisation but serve identical purposes giving the AI agent clear, structured context before implementation begins.

An implementation that follows the spec rather than drifting from it. This is a quality concern about how the AI agent implements, not a structural concern about which tool produces the spec. BMAD's bmad-dev-story is designed to implement against the story file which is derived from SPEC.md. The implementation follows the spec by design. Adding Spec Kit's implementation workflow on top of BMAD's does not make the implementation more faithful to the spec, it creates two parallel implementation paths with no clear boundary between them.

What dual-tool artifact sprawl actually looks like

Running BMAD and Spec Kit simultaneously is not a theoretical concern. Teams that do it encounter a specific and predictable set of problems.

Two artifact hierarchies in the same repository. BMAD produces: PRD.md, ARCHITECTURE-SPINE.md, epic-N.md, story-[JIRA-ID]-[slug].md, sprint-status.yaml. Spec Kit produces: spec.md, constitution.md, task execution plans, implementation artifacts. Both live in _bmad-output/ or equivalent. Engineers cannot tell by looking at a folder which tool's artifacts are authoritative for which work item.

Two context-loading patterns. BMAD's bmad-dev-story loads the story file, which was derived from epic-N.md, which was derived from PRD.md or SPEC.md. Spec Kit loads spec.md and constitution.md directly. When an engineer runs a session in one tool, the agent loads context from that tool's artifact hierarchy. The other tool's context is not loaded. The two agents have different pictures of the same work.

Naming collisions. Both tools produce files named spec.md or similar. BMAD's bmad-spec produces SPEC.md. Spec Kit produces spec.md. In a repository where both tools are active, these files exist side by side. Engineers and the AI agents have to know which one is the active source of truth for which story. In practice, they often do not.

Ceremony duplication. A team running both tools holds a Spec Readiness session using BMAD's bmad-create-story and bmad-testarch-atdd, and also a Spec Kit session to generate the task execution plan and spec.md. The work of understanding the story is done twice. The outputs are not identical. The discrepancies create confusion at implementation time.

Definition of Done confusion. BMAD's Definition of Done involves TEA quality gates, traceability via bmad-testarch-trace, and a specific gate sequence from Gate 1 through Gate 4. Spec Kit has its own completion criteria. When both tools are running, the team has two implicit definitions of done operating simultaneously with no mechanism to reconcile them.

The constitution.md versus project-context.md question

One thing teams genuinely find valuable in Spec Kit is constitution.md, the non-negotiable rules that govern every AI-generated solution. No invented components, no references to non-existent libraries, adherence to team coding standards, specific security and compliance rules.

This is not a Spec Kit capability. It is a BMAD capability surfaced differently.

BMAD's project-context.md serves the same function, it is the project constitution for all AI agents. It contains the tech stack, naming conventions, testing approach, framework patterns, and architectural constraints. Every BMAD agent loads it as a persistent fact.

The customisation we have already established in our Agentic Sprint Delivery configuration goes further: project-context.md conventions are embedded into every story file at creation time, snapshotted at the moment the story was planned. This gives each story its own self-contained constitution. The rules that apply to this story, from this sprint, at this point in the codebase's evolution.

If your team finds constitution.md valuable, the right response is to ensure your project-context.md is comprehensive and that your bmad-create-story customisation embeds it correctly into story files. Not to add a second tool.

When Spec Kit genuinely makes sense

To be fair, there is a scenario where Spec Kit is the right tool.

If your team is not using BMAD and wants spec-driven development for implementation without the full planning and discovery methodology, Spec Kit is a clean, lightweight entry point. It does not require a PRD. It does not require epics or architecture documents. It takes a specification and drives implementation from it.

For teams that want spec-driven development on small, isolated work without any of BMAD's planning infrastructure, Spec Kit is appropriate.

But that is precisely the scenario where BMAD's Quick Flow bmad-quick-dev also applies. And if your team is already using BMAD for planning, you already have the implementation half of what Spec Kit provides. Adding Spec Kit on top does not extend your capability, it duplicates it with a different naming convention and a separate artifact hierarchy.

The practical recommendation

For teams already using BMAD:

For new capability work: Use BMAD's full planning pipeline (PRD, architecture, epics, stories, ATDD, implementation). This is what BMAD was designed for.

For legacy enhancements, bugs, and tech debt: Use bmad-spec as your entry point. Skip Phases 1–3. The SPEC.md is your specification. bmad-create-story derives the story file from it. bmad-testarch-atdd generates the failing test scaffold from the story file. bmad-dev-story implements against the story file. This is spec-driven development. It does not require a Spec Kit.

For trivial single-fixes: Use bmad-quick-dev. The intent clarification and inline spec generation inside Quick Flow is sufficient. No external tool needed.

For your project conventions and standards: Maintain a comprehensive project-context.md. Customise bmad-create-story to embed the relevant sections into every story file. This is your constitution. It travels with every story.

The teams that get the most value from BMAD are not the teams that supplement it with additional spec tools. They are the teams that understand which BMAD entry point is appropriate for each type of work and use it correctly.

That is the whole game. The workflow does not always have to start with a PRD. It just has to start at the right place.

This article is based on ToolTwist's production experience building the Agentic Sprint Delivery (Brownfield) configuration.