# Best spec-driven development tools in 2026

Canonical: https://specscore.md/spec-driven-development/tools/

SpecScore is an open, lintable file format for specifications, written in Markdown and YAML (YAML Ain't Markup Language). [Spec-driven development](https://specscore.md/spec-driven-development/) (SDD) is a practice where a written specification is the source of truth that code is built against and checked against. Spec-driven development tools are the formats, workflows, and products used to write, store, and sometimes check those specifications. A product requirements document (PRD) is prose that states the problem and the scope before anyone splits it into tasks. [Easy Approach to Requirements Syntax](https://kiro.dev/docs/specs/feature-specs/) (EARS) is a requirement sentence of the form “WHEN something happens, THE SYSTEM SHALL do something.” A [command-line interface](https://specscore.md/cli/) (CLI) is a program you run in a terminal. [Continuous integration](https://specscore.md/validators/) (CI) is an automatic check on every proposed change.

This spec-driven development tools comparison covers [GitHub Spec Kit](https://github.com/github/spec-kit), [OpenSpec](https://github.com/Fission-AI/OpenSpec), [Kiro](https://kiro.dev/), [Tessl](https://docs.tessl.io/), the [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), [Task Master AI](https://github.com/eyaltoledano/claude-task-master), [CodeSpeak](https://codespeak.dev/), [Datarim](https://github.com/Arcanada-one/datarim), plain Markdown, and [SpecScore](https://specscore.md/). Public pages and repositories were read on 30 October 2026. Commands, file layouts, and what a product checks can change; the sources at the bottom name the page each claim comes from.

The split that matters for a repository is whether the specification can fail CI on its own. In the SpecScore website repository, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) installs the SpecScore CLI and runs `specscore spec lint` on pull requests and on pushes to main. The [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) skill in specstudio-skills is a manual AI grade of an artifact. You invoke it. That workflow does not.

## Spec-driven development tools, side by side.

Each row is a role, not a score. Follow the name to the SpecScore comparison, or the heading below for the source behind the cell.

| Tool | What it is | How specs are written and stored | Automatic spec validation | Licence | Who it suits |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/vs/spec-kit/) | Agent workflow that produces Markdown artifacts | Feature directory under `specs/`: `spec.md`, `plan.md`, `tasks.md` | `/speckit.analyze` reports cross-artifact gaps in the agent session. Community extensions can add gates. | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) in [github/spec-kit](https://github.com/github/spec-kit) | A team that wants one shared process for the agent |
| [OpenSpec](https://specscore.md/vs/openspec/) | Change folders and agent commands for agreeing before code | Plain Markdown under `openspec/changes/`: proposal, specs, design, tasks | `openspec validate` checks change and spec structure and can exit non-zero, including from a CI script. | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) in [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | A team that wants a light change folder plus a structure check |
| [Kiro](https://specscore.md/vs/kiro/) | AWS agentic IDE, CLI, and web app that drafts specs | `requirements.md` in EARS, plus `design.md` and `tasks.md` | Analyze Requirements inside Kiro, before design. The feature-spec page describes that in-product check. | IDE and CLI are AWS Content under the [Kiro license](https://kiro.dev/license/) (AWS Customer Agreement). | Someone who wants Kiro to draft the requirements, design, and tasks |
| [Tessl](https://specscore.md/vs/tessl/) | Platform for agent skills, plus a spec-driven development tile | Skills as files in the repo. The tile writes `.spec.md` under `specs/`. | The tile ships `scripts/validate-specs.sh` and `scripts/check-spec-links.sh`. Its GitHub Actions lint the tile. | Tile is [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) in [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile). The platform is Tessl’s product. | A team standardizing agent skills, or using the tile’s spec-before-code rules |
| [BMAD Method](https://specscore.md/vs/bmad-method/) | Agile method for AI-driven development | Briefs, specifications, and architecture you can carry into another workflow | The README describes the method’s artifacts and agent workflows. It does not document a format linter for CI. | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) in [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD), with a trademark notice in that file. | A team that wants an agile agent method sized to the change |
| [Task Master AI](https://specscore.md/vs/task-master-ai/) | Task list for coding agents, parsed from a PRD | PRD prose, often `.taskmaster/docs/prd.txt`, then generated tasks | The README describes parsing a PRD into tasks. It does not describe a linter for the PRD. | [MIT with a Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) in [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | A team that already has a PRD and wants it split into tasks |
| [CodeSpeak](https://specscore.md/vs/codespeak/) | Agentic toolkit that turns chat intent into requirements mapped to code | Structured requirements inside the product, mapped to the code | The site says requirements are enforced on every change, inside the product. | [Terms of service](https://codespeak.dev/terms-of-service) (effective 3 March 2026): CodeSpeak Ltd retains the Service, including its source code. The product site does not publish a toolkit source repository. | A team that wants intent captured from chats and kept mapped to code |
| [Datarim](https://specscore.md/vs/datarim/) | Iterative workflow for Claude Code, Codex CLI, Cursor, and Antigravity | `/dr-prd` writes a PRD. Active tasks sit in `backlog.md`. | `/dr-compliance` and `/dr-dream lint` run when you invoke those commands. | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) in [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | A team that wants staged commands and a backlog in the repo |
| [Plain Markdown](https://specscore.md/vs/plain-markdown/) | An ordinary Markdown file you write and commit | Any `.md` file, in whatever directory you choose | Whatever review you do by reading, until you add a checker | No product and no licence file. The file’s terms are the repository’s. | A short note, a spike, or a review you will do by reading |
| [SpecScore](https://specscore.md/) | Open spec format plus a CLI that lints the files | Markdown + YAML in a `spec/` tree | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) runs `specscore spec lint` on pull requests and pushes to main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) is a manual AI grade, and that workflow does not run it. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) format in [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) CLI in [specscore/specscore-cli](https://github.com/specscore/specscore-cli). | A team that needs the spec file to fail CI when the format breaks |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) is an open toolkit that hands a coding agent a process: Specify, Plan, Tasks, Implement, and Converge. The Spec Kit documentation home, dated 28 September 2026, says each phase produces a Markdown artifact the next phase reads.

Those files live in a feature directory under `specs/`. The [upgrade guide](https://github.github.io/spec-kit/upgrade.html), read 30 October 2026, gives paths such as `specs/001-my-feature/spec.md`, with `plan.md` and `tasks.md` beside it. The [agentic SDD reference](https://github.github.io/spec-kit/reference/agentic-sdd.html) describes `/speckit.analyze` as a report of inconsistencies across the spec, the plan, and the tasks, without editing the files. `/speckit.clarify` and `/speckit.checklist` are further commands you run in the agent. The documentation home also names community extensions, including one called CI Guard, that add compliance gates.

The licence is [MIT](https://github.com/github/spec-kit/blob/main/LICENSE), in the public repository [github/spec-kit](https://github.com/github/spec-kit). Spec Kit suits a team that wants that process and is content to keep the specification as the Markdown the agent wrote. A side-by-side with SpecScore is on [SpecScore vs Spec Kit](https://specscore.md/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec), from Fission-AI, keeps each change in its own folder so a person and an agent can agree before code is written. The [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), read 30 October 2026, shows `openspec/changes/add-dark-mode/` with `proposal.md`, a `specs/` directory, `design.md`, and `tasks.md`. Requirements are plain Markdown: a SHALL statement and a WHEN / THEN scenario. The same README says it supports 30+ AI assistants.

`openspec validate` checks changes and specs for structural issues. The [CLI reference](https://openspec.dev/docs/cli), read 30 October 2026, documents a non-zero exit when validation fails, and a shell snippet a CI job can run. That check is OpenSpec’s change and spec structure.

The licence is [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), in [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). OpenSpec suits a team that wants the change folder and that structure check. See [SpecScore vs OpenSpec](https://specscore.md/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/), from Amazon Web Services (AWS), is an agentic development environment: an editor, a CLI, and a web app. The [feature specs page](https://kiro.dev/docs/specs/feature-specs/), updated 4 August 2026, walks a feature through requirements, design, and tasks. `requirements.md` uses EARS. `design.md` and `tasks.md` sit beside it. Quick Spec can run all three without an approval stop between them.

Analyze Requirements looks for inconsistencies, ambiguity, conflicting constraints, and gaps before design. That analysis runs inside Kiro. The feature-spec page describes the in-product check.

The [Kiro license](https://kiro.dev/license/), read 30 October 2026, says the IDE and the CLI are licensed as AWS Content under the AWS Customer Agreement or another written agreement, and the AWS Intellectual Property License. Kiro suits someone who wants that product to draft the three files. See [SpecScore vs Kiro](https://specscore.md/vs/kiro/). The sentence patterns are in [EARS requirements syntax](https://specscore.md/articles/ears-requirements/).

## Tessl

[Tessl’s documentation](https://docs.tessl.io/), read 30 October 2026, describes an open platform for managing agent skills: a registry, governance, evals, and related controls. Skills, rules, and docs are files in the repository.

A separate artifact, the spec-driven development tile, is published from [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) and listed on the [Tessl registry](https://tessl.io/registry/tessl-labs/spec-driven-development). The tile README says the agent writes `.spec.md` files in a `specs/` directory, with YAML frontmatter, `targets`, and `[@test]` links. It documents `scripts/validate-specs.sh` and `scripts/check-spec-links.sh`, and GitHub Actions that lint the tile itself.

The tile’s licence is [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), in that repository. The docs describe the registry platform as Tessl’s product and do not point at a public repository for the whole platform. Tessl suits a team standardizing skills, or a team that wants the tile’s spec-before-code steering. See [SpecScore vs Tessl](https://specscore.md/vs/tessl/).

## BMAD Method

The [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD) repository README, read 30 October 2026, describes an agile method for AI-driven development. It says you can use the method end to end, or carry its briefs, specifications, and architecture into a workflow you already have. The stable line named there is v6.12. v7 is described as a preview on the main branch. The project spells the name BMad; the repository is BMAD-METHOD.

The README centres those planning artifacts and the agent skills that produce them. It does not document a command that lints a fixed spec schema in CI.

The licence is [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), in [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD). That licence file also carries a trademark notice for BMad. The method suits a team that wants the agile loop and will keep the specification in those briefs and specs. See [SpecScore vs the BMAD Method](https://specscore.md/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) is a task list for AI coding agents. The README, read 30 October 2026, recommends a PRD, often at `.taskmaster/docs/prd.txt`, and `task-master parse-prd` to turn that prose into tasks. [The docs](https://tryhamster.com/docs/taskmaster) cover task structure, dependencies, and tags.

The README treats the PRD as input and the task list as what the agent works from. It does not describe a linter for the PRD’s wording or structure.

The licence is [MIT with a Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), in [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master). The README says you may build products with Task Master, and that selling Task Master itself or offering it as a hosted service is outside that grant. It suits a team that wants the PRD split into tasks. See [SpecScore vs Task Master AI](https://specscore.md/vs/task-master-ai/).

## CodeSpeak

[CodeSpeak](https://codespeak.dev/)’s site, read 30 October 2026, describes an agentic engineering toolkit. It captures intent from agent chats, turns that intent into structured requirements mapped to the code, and says it enforces those requirements on every change. The site also says a web tool recovers intent from chats until the full product launches.

The [terms of service](https://codespeak.dev/terms-of-service), effective 3 March 2026, state that CodeSpeak Ltd retains the Service, including its software and source code. The product site does not publish a source repository for that toolkit, so this page does not name a software licence for it.

CodeSpeak suits a team that wants requirements captured from conversation and kept mapped to code inside that product. See [SpecScore vs CodeSpeak](https://specscore.md/vs/codespeak/).

## Datarim

[Datarim](https://github.com/Arcanada-one/datarim)’s README, carrying a 4.9.0 version badge and read 30 October 2026, describes an iterative workflow for Claude Code, Codex CLI, Cursor, and Google Antigravity. `/dr-prd` generates a PRD. Active tasks sit in `backlog.md`, with completed history in `backlog-archive.md`.

`/dr-compliance` checks an implementation against the PRD when you run that command. `/dr-dream lint` health-checks a knowledge base for contradictions, orphans, broken links, stale content, and duplicates. Those are commands in the workflow.

The licence is [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), in [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim). Datarim suits a team that wants those staged commands across the agents the README names. See [SpecScore vs Datarim](https://specscore.md/vs/datarim/).

## Plain Markdown

Plain Markdown is the specification as an ordinary `.md` file: a heading, some bullets, wherever you commit it. There is no schema. Review is someone reading the file, until you add a checker of your own.

There is no product and no licence file to link. The file’s terms are whatever licence you apply to the repository. Plain Markdown suits a short note, a spike, or a team that will review the prose by reading it. See [SpecScore vs plain Markdown](https://specscore.md/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/) is a format for the specification — features, requirements, and acceptance criteria as Markdown with YAML — and a CLI that checks the files. The format lives in [specscore/specscore](https://github.com/specscore/specscore). The CLI lives in [specscore/specscore-cli](https://github.com/specscore/specscore-cli).

How to write the criteria so an agent can check them is in [how to write acceptance criteria](https://specscore.md/articles/acceptance-criteria/).

A Markdown feature spec template — requirements, acceptance criteria, a plan, and tasks — is in [PRD template in Markdown](https://specscore.md/articles/feature-spec-template/).

Claude Code spec-driven development and Cursor specs — the feature file, the agent instruction file, and `specscore spec lint` in the loop — are in [spec-driven development with Claude Code and Cursor](https://specscore.md/articles/claude-code-specs/).

In this website’s repository, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) installs that CLI and runs `specscore spec lint` on pull requests and on pushes to main. A spec that breaks the format fails that job. How to run that check is in [lint specs in CI](https://specscore.md/articles/lint-specs-in-ci/). The [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) skill is a manual AI grade: it re-runs the configured reviewers when you ask, and the dogfood workflow does not call it.

The format licence is [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), in [specscore/specscore](https://github.com/specscore/specscore). The CLI licence is [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), in [specscore/specscore-cli](https://github.com/specscore/specscore-cli). SpecScore suits a team that needs the specification to fail CI when a heading, a link, or a status is wrong, whichever agent wrote the file. `openspec validate` is the closest structural check among the other tools here; it checks OpenSpec’s own change shape. The individual comparisons start at [/vs/](https://specscore.md/vs/).

## How to choose.

Choose GitHub Spec Kit, OpenSpec, the BMAD Method, or Datarim when you want a guided process and Markdown you can review in a pull request. Choose Kiro when you want that product to draft EARS requirements. Choose Task Master AI when the PRD should become a task list. Choose CodeSpeak when the intent should be captured from chats inside that product. Choose Tessl when the problem is agent skills, with the spec tile as an optional steer.

Choose SpecScore when the specification file itself has to fail CI. The check in this repository is `specscore spec lint` in [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). A workflow from the list above can still be how the spec gets written.

## Sources.

Read on 30 October 2026, except where a page prints its own updated date. Prices and plan names are omitted because they move.

- [GitHub Spec Kit docs (page dated 28 September 2026)](https://github.github.io/spec-kit/)
- [Spec Kit — Agentic SDD reference](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — Upgrade guide (specs/ paths)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — MIT licence](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [OpenSpec CLI reference — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — MIT licence](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Kiro docs — Feature specs and EARS (updated 4 August 2026)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — License](https://kiro.dev/license/)
- [Tessl docs — What is Tessl?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tessl spec-driven development tile — MIT licence](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD — README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — MIT licence](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master — README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master — MIT with Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — Terms of service (effective 3 March 2026)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (4.9.0 badge)](https://github.com/Arcanada-one/datarim)
- [Datarim — MIT licence](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml (specscore spec lint)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — /score skill (manual AI grade)](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)