TLM Forge vs BMAD-METHOD vs GitHub Spec Kit

TLM Forge, BMAD-METHOD, and GitHub Spec Kit compared on merge gates, adversarial review, and test evidence, not just spec-writing.

TLM Forge, BMAD-METHOD, and GitHub Spec Kit all start from the same premise: an agent should work from a written spec instead of a bare prompt, broken into stages rather than one long generation. Only TLM Forge turns that spec into an enforced, scored gate that blocks a bad diff from merging. Those are the three names that keep coming up when a team looks for this kind of structure around AI coding agents, and the similarities between them stop at the plan.

What separates the three is what happens after the spec exists and the agent starts writing code. A plan that lives in a markdown file relies on the agent, and whoever reviews the diff, to notice if a step gets skipped. That question has gotten harder to ignore as more teams give coding agents the ability to open pull requests and push changes on their own, with less of a human standing between the plan and the merge. This comparison sticks to what each tool's own documentation says it does, plus TLM Forge's own published capability list, and skips anything that would require guessing at a competitor's internals.

What each tool is

BMAD-METHOD, first published in April 2025, runs AI-assisted development through a repeating loop: clarify a rough idea, plan it out in more depth, build and verify the resulting change, then learn and adjust before the next pass starts. During planning, different AI agents take on different perspectives, covering product, architecture, and testing concerns before any code gets written. The loop is meant to size itself to the work: a small fix can go straight to implementation, while a larger initiative runs the full planning cycle first.

Sources: BMAD-METHOD

GitHub Spec Kit, started in August 2025, structures the same idea as a fixed sequence of commands run inside a coding agent. Constitution sets project-wide principles once, specify captures what needs building, clarify resolves open questions before planning starts, plan produces a technical approach, tasks breaks that plan into discrete units of work, and implement carries the tasks out. Each command reads the document the previous one produced, so the sequence runs roughly in order.

Sources: GitHub Spec Kit

TLM Forge starts from the same spec-first premise, then adds a step neither of the above tools includes: a mechanical check on whether the plan was actually followed. It requires a spec and a diagram sign-off before implementation begins, runs the resulting diff through adversarial multi-agent review, and scores the outcome as a gate rather than a recommendation. It is built specifically for Claude Code, using its hooks, sub-agents, and MCP support to make that gate enforceable instead of advisory.

The basics all three cover

Writing a spec and a plan before code, running that plan through a structured, staged workflow, and carrying project context forward instead of re-explaining it in every session: all three tools do this now. That is worth stating plainly. A spec-first workflow is table stakes for a serious AI coding setup in 2026, not a differentiator. The interesting question is what each tool does once the plan exists and the agent starts generating a diff against it.

Where the three actually diverge

Nothing below claims an advantage for BMAD-METHOD or Spec Kit: a competitor either matches a row or it does not, and the comparison only tracks what TLM Forge's own published capability list documents. The table lists TLM Forge's specific edges first, the shared basics in the middle for reference, and the capabilities unique to TLM Forge last. One item, cross-project team-wide memory, is marked as a roadmap item rather than a shipped feature, because it is not live yet.

Structure you can skip is not a guarantee

A workflow an agent can skip is a suggestion, not a control. BMAD-METHOD and Spec Kit both hand the agent a sequence of steps, and a well-behaved agent generally follows them in order. Neither tool's own documentation describes a mechanism that stops a merge if a step gets skipped or a serious issue in the diff goes unaddressed. TLM Forge makes that check mechanical: a commit-gate hook looks for unresolved critical findings and refuses the merge until they are cleared, regardless of what the agent claims it did.

Adversarial review finds different bugs than cooperative review

Most review setups, human or AI, start from the assumption that the work in front of them is basically sound and look for polish on top of it. TLM Forge's review agents start from the opposite assumption. A threat-modeler examines the design before any code exists, and a separate red-team agent attacks the finished diff, both running in fresh context with no stake in the code being good. That produces a different set of findings than an agent checking its own output, or a second cooperative agent asked to confirm the first agent's work looks fine.

A scored gate, not an opinion

'Looks good' is not a data point a gate can check twice. TLM Forge scores every review finding and treats even one unresolved critical as a hard stop, no matter how favorably the rest of the review reads. That is a narrower, more mechanical bar than a general instruction to review the code carefully, and it is the piece BMAD-METHOD's and Spec Kit's own documented workflows do not include.

Tests that leave a receipt

TLM Forge also enforces test-driven development directly. A failing test has to exist before the fix that makes it pass, and the full suite has to run green with that run captured as evidence. That turns 'the tests pass' into something a reviewer can go back and reproduce, instead of a line in a chat transcript that has to be taken on trust.

Depth over breadth: built for Claude Code specifically

TLM Forge does not try to run identically across every coding agent on the market. It is built on Claude Code's own hooks, sub-agents, and MCP support, the machinery that lets a merge gate actually block a commit instead of just suggesting one. That trade-off cuts the other way too: a team standardized on a different coding agent will not get the same enforcement from TLM Forge, because the mechanism depends on the platform underneath it, not just on the workflow written on top.

Claims you can check against the code

Two of the capabilities unique to TLM Forge among these three are about accountability rather than process. Every behavior claim a review makes has to cite the specific file and line it is about, so a finding reads as something a reviewer can go verify rather than a general impression of the diff. Paired with that, TLM Forge keeps a reproducible audit trail running from the original spec through to the evidence that a change met it, so a team can reconstruct after the fact why a particular change was allowed to ship.

A roadmap item is not a shipped feature

Cross-project, team-wide memory sits on TLM Forge's own roadmap, not in the product today. It is listed here because comparison honesty cuts both ways. A tool's own description should not claim a shipped feature that is not there yet, any more than it should claim an edge a competitor happens to have.

What to check before adopting any of these

None of this is an argument against BMAD-METHOD or Spec Kit for what they are built to do: getting a team from a vague idea to a written, staged plan an agent can execute against. The questions below apply regardless of which framework, or none, a team is currently running.

• Whether a skipped step actually blocks anything, or only shows up if a human happens to notice
• Whether the same agent that wrote the code is also the one reviewing it
• Whether a passing test suite is captured as reproducible evidence or just reported as a claim
• Whether unresolved critical findings can still merge if nobody catches them in time
• Whether a review finding can be checked against a specific file and line, or only against a general impression of the diff
• Whether the workflow fits how the team already uses its coding agent, rather than replacing it

TLM Forge exists to close that specific distance for teams building on Claude Code. It requires the spec and diagram sign-off described above before implementation starts, runs the adversarial review pass on the resulting diff, and will not let a change merge while a critical finding is still open. None of that removes the need for engineering judgment. It means that judgment gets checked against a gate instead of assumed from a green checkmark, and it means the check happens the same way on every pull request instead of depending on which reviewer is available that day.