SpecScore vs Tessl
Spec-driven development (SDD) means the specification of intended behavior is written before the code. Tessl (Tessl AI Ltd) is, as of 30 October 2026, an agent enablement platform: a registry and control plane for the skills, rules, and plugins that coding agents load. “Spec as source” is the stronger claim in Tessl’s June 2025 essay: the specification is the long-lived artifact, and code is derived from it. SpecScore is an open-source file format for that specification, checked by a command-line interface (CLI). Continuous integration (CI) — an automatic check on every proposed change — runs that check in this repository.
What they share.
What Tessl does well.
Two different Tessl surfaces are easy to mix up. The notes below keep them apart, from pages read on 30 October 2026.
A clear argument for spec as source
Simon Maple’s essay of 27 June 2025 says a product requirements document (PRD) — prose written for people about what to build — usually goes stale, while the code becomes the only source of truth. The essay’s alternative is that the spec is what you change, and an LLM generates code, tests, and docs from it. That is a real position, not a slogan.
A platform for agent context
Tessl’s docs describe a registry, governance that scans and scores skills, evals, and observability across agents. The docs say skills are plain artifacts in your repo, and that the platform works with Claude Code, Cursor, Copilot, Gemini, and others. Scoring there means scoring a skill, not scoring a product spec.
An official spec-driven tile with shell checks
The tessl-labs/spec-driven-development tile, MIT-licensed in the public tile repository, teaches an agent to interview, write .spec.md files, wait for approval, then implement. The registry page lists scripts/validate-specs.sh and scripts/check-spec-links.sh for frontmatter, targets, and [@test] links. The same page says the tile is steering context: no special commands, no framework.
Feature comparison.
“Spec as source” is Tessl’s essay. The tile is a skill pack on top of today’s platform. SpecScore is a format with a versioned linter.
| Capability | Tessl | SpecScore |
|---|---|---|
| Primary role | Agent-skills platform, plus a spec-driven tile and a 2025 essay on spec as source | Open spec format + CLI |
| What the spec is | Essay: the long-lived source code is generated from. Tile: a .spec.md the agent implements against, and you keep the code. | A contract beside the code. Lint does not regenerate the code. |
| Spec shape | Tile: YAML frontmatter, targets globs, and [@test] links to test files | Markdown + YAML, REQ: slug, Given/When/Then |
| Checking the spec | Shell scripts shipped with the tile, for that tile’s frontmatter and links | specscore spec lint on the SpecScore format, in this repo’s CI. /score is a manual AI grade. |
| License | The tile is MIT. The platform is a product. The docs do not publish the platform’s source code. | CC BY 4.0 format · Apache-2.0 CLI |
| Price | The Tessl homepage, read 30 October 2026, describes a free tier (1,000 credits a month on one workspace) and paid enterprise plans. | No fee for the format or the CLI |
What SpecScore adds.
A published format, not a tile script
The tile’s shell scripts check .spec.md files that tile asked the agent to write. SpecScore checks a format documented on this site. dogfood.yml installs a pinned specscore release and runs specscore spec lint. /score is not that job: it is a manual skill that exits non-zero when AI reviewers report issues.
$ 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)
You keep the code either way — the essay goes further
The 2025 essay says code should be regenerated from the spec. The tile, on the page read 30 October 2026, has the agent implement against an approved spec and does not describe a compiler that replaces your source tree. SpecScore never takes the code away. The spec is the reviewed contract; the code stays yours.
Requirement identity
The tile points a requirement at files with targets and [@test]. SpecScore names the requirement REQ: slug so a plan, a task, and a commit trailer can cite it after the files move.
When to use which.
Reach for Tessl when…
- You need a registry, evals, and governance for skills shared across many agents and repositories.
- You want the spec-as-source essay’s workflow as a steering tile: interview, approve a .spec.md, then implement.
- You are already paying for, or trying, the Tessl platform and want its spec tile in that registry.
Use SpecScore when…
- The spec format itself has to be valid in CI, including in repos that do not install Tessl.
- You want requirement ids and a linter that does not call a model.
- You want the format open-source under a Creative Commons license, separate from a skills platform.
Spec as source, and a spec you can lint.
Tessl’s essay is right that a stale PRD loses to the code. A format check is how the spec stays the thing you trust. SpecScore does not generate your application from the spec. It makes the spec fail CI when the structure, the links, or the status are wrong.
Use Tessl if you want the platform and the tile. Use SpecScore if the artifact in git is what the pull request must prove.
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.