Level 9Lesson 75⏱️ 40 min

The SDD Toolbox

A tour of the tools that turn spec-driven development from a nice idea into a real workflow - and how to tell them apart

The Landscape in One Picture

SDD went from a blog-post idea to a crowded toolshelf in about a year. The tools differ mostly on one question: does the spec get read once and thrown away, or does it stay a living asset the agents keep executing against? Keep that question in mind as we tour them.

Reality check (a survey from early 2026): ~90% of developers use AI at work, but only ~13% use it across the whole development lifecycle. SDD tools are how teams close that gap - moving AI from "autocomplete" to "runs the process."

GitHub Spec Kit - The Popular Starting Point

Spec Kit is GitHub's open-source SDD toolkit - by mid-2026 it had passed 90,000 stars and worked with 30+ coding agents (Claude Code, Cursor, Copilot, and more). It gives you slash commands that walk you through the SDD loop, each producing a Markdown file that feeds the next.

The Spec Kit commands map exactly onto the SDD loop:

/speckit.constitution   → write the governing principles
/speckit.specify        → generate a detailed spec from your idea
/speckit.plan           → turn the spec into a technical plan
/speckit.tasks          → break the plan into small, testable tasks
(then your agent implements each task)
Why it's a good first tool: it's free, tool-agnostic, and the artifacts are just Markdown you can read and edit. It makes the four-step loop concrete without committing you to one vendor.

The Other Players

Amazon Kiro

An AI IDE built around specs. It generates requirements, design, and tasks as you go, and treats them as first-class files in your project.

OpenSpec

An open-source approach focused on keeping a clean, versioned spec that the agent works against - lightweight and tool-agnostic.

Tessl

Pushes the idea furthest: the spec is treated almost like the "real" source, with code as a regenerable output. The strongest version of "specs are the source of truth."

Cursor rules (.cursor/rules)

Not a full SDD system, but the lightweight cousin - standing project rules the agent reads every time. The instruction pillar, basically.

Read-Once vs. Living Specs

This is the distinction that actually matters when you choose. It's a spectrum:

READ-ONCE                                      LIVING
(spec scaffolds the next change, then fades)   (spec is enforced forever)

  Spec Kit (lighter)  ───────────────────────▶  BMAD, LID, Tessl
  "generate code from a spec, move on"           "every piece of code must
                                                  trace back to a current spec"
Which do you want? Read-once is great for shipping a feature fast. Living specs cost more upfront but pay off on long-lived projects where you need to know, months later, why every line exists. The two heavyweight "living" systems - BMAD and LID - are the next four lessons.

Where BMAD and LID Fit

You're about to go deep on two named methods. Here's the one-line difference so you have a map:

BMAD  - "a whole AI product TEAM"
        Specialized agents (PM, Architect, Dev, QA...) run an
        agile process that produces planning docs, then code.
        Great when you want structure, roles, and governance.

LID   - "a traceability GRAPH rooted in intent"
        Every code file traces back through a test, a spec, a
        design, up to one high-level intent - enforced by a gate.
        Great when you want provable "why does this code exist?"

Hands-On: Try the Loop in Any Tool

Hands-on (15 min): You don't have to install anything. In any AI assistant, manually run the Spec Kit loop on a tiny idea ("a tip calculator"): ask it to write a one-paragraph constitution, then a spec (with EARS requirements from last lesson), then a plan, then a task list - approving each before the next. Notice how much more grounded the final task list feels than if you'd just said "build a tip calculator." That's SDD with zero tooling - the tools just automate this.
Lesson 75 Quick Reference
GitHub Spec Kit

Popular open-source SDD toolkit; /speckit.constitution → specify → plan → tasks; works with 30+ agents

Amazon Kiro

An AI IDE built around specs as first-class files (requirements, design, tasks)

OpenSpec / Tessl

OpenSpec keeps a clean versioned spec; Tessl pushes "spec is the real source, code regenerates"

Read-once vs living spec

The key choice: a spec that scaffolds one change vs one enforced forever

BMAD (preview)

A whole AI "product team" of role-based agents running an agile process

LID (preview)

A traceability graph where every code file links back through tests and specs to one intent

← Writing Specs That Don't Lie (EARS)
Unlocks in ~10 min of reading