Fair question. Spec Kit and BMAD are both broader than this. Spec Kit has dozens of agent integrations and an extension ecosystem, BMAD has personas for product, architecture, UX, dev and test. This is narrower and stricter about a few things:

Checking the spec before building. Spec Kit's converge compares the code with the spec after implementation. Here a script first resolves every file and line the spec cites against the current code, then a fresh agent answers BUILD, BUILD WITH CUTS or REFUSE.

A spec built on a wrong assumption gets stopped before any code is written. A commit gate that's part of the method. Every spec commit runs the project's verify stages (build, full test suite) and is blocked if anything is red. In Spec Kit you can add gates through extensions; here the definition of done is enforced by default. Decisions per spec. Every non-obvious choice is logged as chose / over / why, and later agents read it before changing something.

Memory as hints. Facts that don't fit in code or git live in the repo as hints, separate from decisions. In Agent Smith, the server product, a memory's standing comes from the runs that relied on it, so a wrong one can't turn into a rule.

Parallel by design. Each spec runs in its own worktree, and spec ids are minted from the date plus random hex instead of counting existing specs, so agents working in parallel never collide on a number.

YAML instead of Markdown. My first 100 specs in Markdown were 250k tokens; in YAML they're 15k.