Spec Kit, BMAD, Kiro, OpenSpec and the rest: the flavours of SDD

Ask five engineers what spec-driven development means and you may get five answers. One means a set of slash commands in GitHub Spec Kit. Another means the product manager and architect personas of the BMAD Method. A third means the three files Kiro writes before it touches code. A fourth means OpenSpec’s change proposals. And the platform engineer means none of these: to them it is the sandbox, the tests and the pipeline that agents run inside.

None of them is wrong. They are describing different parts of the same problem. Choosing well starts with seeing which part each approach actually addresses, because most teams end up combining two or three.

We are following Kestrel Mutual, a fictional South African insurer building assisted account recovery for customers who can no longer receive a sign-in PIN on their registered mobile number. Kestrel is fictional, and all figures are illustrative. Kestrel is deliberately tool-neutral in this series: the point is to understand the approaches, not to endorse a product.

They solve different parts of the problem

GitHub Spec Kit

Spec Kit is an open-source (MIT) toolkit from GitHub whose own description is about defining what to build before building it, with any AI coding agent. GitHub announced it in September 2025, and it has grown quickly since. It is agent-neutral: its documentation lists integrations with more than thirty coding agents, including GitHub Copilot, Claude, Gemini, Codex and Kiro. A command-line tool, specify, sets a project up.

The workflow runs as slash commands inside the agent:

1. /speckit.constitution writes the project’s durable rules.
2. /speckit.specify describes the need and the behaviour.
3. /speckit.clarify (optional, recommended before planning) asks about material ambiguity.
4. /speckit.plan produces the technical approach, along with research notes, a data model, contracts and a quickstart.
5. /speckit.tasks breaks the plan into executable tasks.
6. /speckit.analyze (optional) checks the spec, plan and tasks for consistency before any code is written.
7. /speckit.implement carries out the tasks.
8. /speckit.converge compares the codebase with the spec, plan and tasks, and adds any remaining work as new tasks. Implement and converge repeat until it reports that they have converged.

Choose it when a team wants a recognisable, relatively lightweight process that works the same way whichever agent people prefer. For Kestrel, a Spec Kit-style constitution is where a rule such as “no reset completes below the required identity assurance” would live.

The caution applies to every template: a generated spec is not correct because it fills in every heading. Only a person who understands fraud at an insurer can tell whether the spec is right.

BMAD Method

The BMAD Method (the repository expands it as Breakthrough Method for Agile AI Driven Development) is broader than a feature-spec template. Its current documentation presents an adaptive method in which decisions stay explicit, context carries forward, and the process sizes itself to the work. Product, architecture, UX, development and testing perspectives each shape the result.

It installs five named agent personas: Analyst, Product Manager, Architect, Developer and UX Designer. It sizes work from trivial through one-session and epic-sized to project-sized, and trivial changes go straight to build. Its delivery loop is clarify, plan, build and verify, then learn and adjust. Along the way it produces artefacts such as a product brief, a PRD (product requirements document), UX design notes, an architecture, and epics and stories.

Choose it when the idea still needs discovery, when several specialist perspectives must shape it, and when the work runs from a product brief all the way to delivery. The caution is proportion. A persona is a structured prompt, not a colleague, and running the full product-to-architecture flow on a two-day change costs more than the change. BMAD’s own sizing exists for exactly that reason, so use it.

Kiro-style requirements, design and tasks

Kiro is AWS’s agentic development environment (we looked at it in Amazon Kiro: what AWS’s AI-native IDE means). Its specs separate three questions into three files:

1. Requirements (requirements.md): what should users and systems observe?
2. Design (design.md): how will the system meet those requirements?
3. Tasks (tasks.md): what sequence will implement and prove the design?

There is an approval gate between each phase. Feature specs can start from requirements or from design, bugfix specs start from an analysis of the bug instead, and a quick spec generates all three files without the gates.

Kiro writes requirements in EARS (Easy Approach to Requirements Syntax), a notation developed by Alistair Mavin and colleagues at Rolls-Royce and first published in 2009. EARS gives each requirement a small, predictable shape: “When” for an event, “While” for a state, “If … then” for unwanted behaviour, “Where” for an optional feature. For Kestrel, one requirement might read:

WHEN a recovery attempt is classified as high risk THE SYSTEM SHALL create a fraud review case AND SHALL NOT reset the credential.

The three-question split is useful even without the tool, which is why this series says “Kiro-style” for the pattern. Its weakness appears when a team approves three documents in turn while they still contradict each other: requirements that promise a 24-hour lockout, and a design that keeps failed attempts for only an hour.

OpenSpec

OpenSpec, an MIT-licensed project maintained by Fission AI, treats a change as a first-class object. The current, durable behaviour of the system lives in openspec/specs/. Each proposed change gets its own folder under openspec/changes/ containing a proposal, delta specs, a design and tasks. A delta spec does not restate everything. It lists only what the change adds, modifies or removes, under the headings ADDED Requirements, MODIFIED Requirements and REMOVED Requirements. When the change is complete it is archived, and its deltas are merged into the main specs.

Requirements use SHALL and MUST wording, the capitalised keywords defined in RFC 2119, with scenarios written as WHEN and THEN. A delta for Kestrel’s existing login might look like this:

## ADDED Requirements

### Requirement: Recovery lockout
The system SHALL lock the recovery flow for 24 hours after three failed checks.

#### Scenario: Third failed check
- **WHEN** a customer fails a third recovery check
- **THEN** the recovery flow is locked for 24 hours and the attempt is recorded

In an agent, the default commands are /opsx:explore, /opsx:propose, /opsx:apply and /opsx:archive.

This suits brownfield software. The question is not only “what should exist?” but “what changes from what we already promise?”, and reviewers see exactly that difference. The caution is ownership: durable specs are only durable if someone is accountable for keeping them true.

Intent architecture

Intent architecture is an emerging umbrella term rather than a standard. It describes connecting product purpose to local coding work, so that a developer or agent receives the relevant slice of context: the outcome, domain language, boundaries, contracts, UI patterns, security controls and acceptance. It is a way of organising context, not a product. Part 4 develops it, including how an agent working on one small task inherits only the rules it needs.

Harness engineering

A specification tells an agent what to build. The harness is everything around the agent that lets it build safely and prove the result: repository instructions, tools, permissions, sandboxes, tests, linters and feedback loops.

OpenAI’s February 2026 write-up, Harness engineering: leveraging Codex in an agent-first world, described a team building a product over roughly five months with Codex writing the code. The repository became the system of record, a short AGENTS.md file acted as a map to deeper documentation rather than an encyclopaedia, architecture rules were enforced mechanically with custom linters and structural tests, and background agent tasks cleaned up drift. Birgitta Böckeler’s commentary on martinfowler.com, “Harness engineering for coding agent users” (April 2026), frames the harness as guides that steer an agent before it acts and sensors that give feedback afterwards.

You will sometimes see “HDD”, for harness-driven development. It is loose usage, not a defined method, and it has nothing to do with Harness, the software delivery company. If your team uses the term, define it. The idea is simple enough:

The spec supplies direction. The harness supplies controlled execution.

Part 5 covers the harness in detail, and Guides, Guards, Checks and Sensors sets out a complementary framework.

The older disciplines still do real work

• BDD (behaviour-driven development) describes behaviour through concrete examples in a Given, When, Then shape. It is excellent for business rules with many exceptions. Examples cannot describe every property, though: ten examples of a lockout do not prove there is no eleventh path around it.
• TDD (test-driven development) writes a failing test before the code that makes it pass. With agents it matters more, not less, as long as the tests come from the approved behaviour rather than from the agent’s own implementation.
• Contract-first design agrees interfaces before building either side: OpenAPI for HTTP APIs, AsyncAPI for event-driven messages, or protobuf. Kestrel’s RecoveryDecision contract lets the portal team and the identity team work in parallel. But a perfectly valid contract can still carry the wrong business decision.

Four workflows, side by side

Side by side, the vocabulary differs far more than the shape. The differences are in emphasis: Spec Kit in a portable, agent-neutral command flow; Kiro in staged approval; OpenSpec in the change as the unit of review; BMAD in the breadth of perspectives before planning.

Combining them

Most real teams mix these approaches. Kestrel’s recovery work shows how: a requirements, design and tasks flow for the new capability, with the fraud rules pinned down as BDD examples; change deltas for later changes once it is live; a contract-first RecoveryDecision interface between portal and identity service; a harness for the agents; and intent architecture because four teams are involved. None of that requires a particular product. Part 9 gives starting points by situation. But do not combine approaches merely to collect terminology.

How these descriptions were checked

The tool descriptions in this part were checked against each project’s official repository and documentation on 14 September 2026. This ecosystem moves quickly: command names have changed since some of these tools launched, and agent line-ups and workflows are still being reorganised. Verify current commands before you adopt one. “Intent architecture” and “harness-driven development” are emerging terms rather than governed standards, and the definitions here are architectural interpretations of current public practice. Teams should define their chosen vocabulary in their own operating model.

What to take from this part

The approaches solve different parts of the problem. Discovery, feature intent, change to existing behaviour, context and execution are separate jobs.

Tools share a shape more than a vocabulary. Capture intent, have a person review it, break it into tasks, verify against it.

Match the approach to the work. Staged feature specs for new capability, deltas for brownfield change, examples for tricky rules, contracts for interfaces.

A spec without a harness cannot prove anything, and a harness without a spec proves the wrong thing. You need both.

Check the commands before you commit. The tools change quickly; the concepts change far more slowly.

Next in the series: Anatomy of a useful specification.

How CloudNala can help

We help teams choose between these approaches on the evidence of their own work rather than on tool popularity: mapping the kinds of change they actually make, matching each to a workflow, and running a short comparison on a real feature so the decision rests on what happened, not on a demo.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Plan an SDD Pilot or write to us at consult@cloudnala.co.za