SpecScore vs the BMAD Method
The BMAD Method (Breakthrough Method for Agile AI-Driven Development) is an open-source way to run agile delivery with AI agents: clarify the work, plan it, build it, and check it, with the decisions written down. A product requirements document (PRD) is the prose description of what to build and for whom; the method’s workflow map produces one, then architecture and stories. Spec-driven development (SDD) is the broader idea both sit in — behavior is specified before code. SpecScore is an open-source format for that specification, plus a command-line interface (CLI). Continuous integration (CI) — an automatic check on every proposed change — can fail when a SpecScore file is structurally wrong.
What they share.
What the BMAD Method does well.
The project README, read 30 October 2026, calls v6.12 the stable release and v7 a preview on the main branch. The v7 date in that README had already passed. Treat the line names as a snapshot.
A method that sizes itself
The README says small changes go straight to build, and larger work gets planning. The workflow map on main spells out phases: a PRD (PRD.md), an optional UX spec, architecture.md with decision records, epic and story files, then a sprint. That is a full agile loop, not a single prompt.
A gate before implementation
The same map lists bmad-check-implementation-readiness, which returns PASS, CONCERNS, or FAIL before implementation. The v6 product-manager agent also has a validate-PRD step. Those are workflow gates the agent runs. They are not a separate format linter you point at an arbitrary Markdown tree.
It is actually published
The method is MIT-licensed in a public repository. The README’s stable install is npx bmad-method install, and it asks for Node.js 20.12 or newer and Python 3.10 or newer. The site bmadcode.com says the method is free.
Feature comparison.
BMAD is the process. SpecScore is the artifact format a process can target. The table compares those roles.
| Capability | BMAD Method | SpecScore |
|---|---|---|
| Primary role | Agile method: agents, skills, and workflows from idea to verified code | Open spec format + CLI |
| Planning artifacts | PRD, UX spec, architecture, epics and stories, sprint status — on the workflow map read 30 October 2026 | Ideas, features, plans, tasks in a spec/ tree, with requirement ids |
| Checking the work | Readiness gate (PASS / CONCERNS / FAIL) and a validate-PRD workflow, run by the agent | specscore spec lint in CI, deterministic. /score is a manual AI grade. |
| Requirement ids | Stories and functional requirements inside the PRD and epic files. Not the SpecScore REQ: slug. | REQ: slug and acceptance-criterion ids |
| Runtime | Node.js and Python for the v6.12 installer described in the README | None beyond a single Go binary |
| License | MIT, bmad-code-org/BMAD-METHOD | CC BY 4.0 format · Apache-2.0 CLI |
What SpecScore adds.
The check is a command, not a step in the method
BMAD’s readiness result is a decision inside its workflow. SpecScore’s result is a process exit code. dogfood.yml runs specscore spec lint on every pull request. /score grades an artifact with the reviewers configured in the repo; you invoke it. CI does not.
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors)
The format survives a different method
BMAD’s documents are shaped by its workflows. If you stop running BMAD, you still have the Markdown, but nothing outside the method enforces the shape. A SpecScore tree is the contract. Another workflow — including BMAD — can write it, and the linter still applies.
Stories and requirements stay linked by id
BMAD stories carry context forward so the agent does not re-decide the product. SpecScore makes the link mechanical: a plan task cites REQ: slug, and specscore: annotations plus Verifies: commit trailers point code back at the criterion.
When to use which.
Reach for the BMAD Method when…
- You want a full agile loop — PRD, architecture, stories, sprint — executed by agents with role-specific workflows.
- You want the readiness gate and the party of product, architecture, and test perspectives the method ships.
- You are standardizing how a team prompts, and the method’s skills are the standard.
Use SpecScore when…
- The specification has to fail CI when a heading, a link, or a status is wrong, even if nobody runs the BMAD workflow that day.
- You need stable requirement ids across tools, not only inside one method’s story files.
- You want a format open-source that a different process can target.
The method can write the format.
BMAD answers “how do we run the work.” SpecScore answers “what file is the contract, and how does CI know it is intact.” A team can keep BMAD’s PRD and stories for the conversation, and keep a SpecScore feature for the requirements that must lint.
Use the BMAD Method for the loop. Use SpecScore for the artifact the pull request checks.
Sources.
The public pages below were read on 30 October 2026. Prices, plan names, and release lines change.
Other comparisons.
The same format, set next to other spec-driven tools:
All of them, on one page: best spec-driven development tools in 2026.
Feedback
This comparison is based on publicly available documentation and source code. Something wrong or outdated? open a correction issue. Want us to compare SpecScore with another tool? request one.