SpecScore vs OpenSpec

Both put specifications in Markdown, next to your code, readable by AI agents. They answer different questions: OpenSpec organizes specs and generates agent commands. SpecScore lints spec content, enforces lifecycle, and traces code back to requirements.

What they share.

Specs live in your repo as Markdown files — version-controlled, PR-reviewable.
Both are open source under the MIT license.
Both use Given/When/Then acceptance criteria.
Both support AI coding agents as first-class consumers of specs.

What OpenSpec does well.

OpenSpec(GitHub) is a spec-driven development framework by Fission AI.

Broadest agent support

OpenSpec supports 29 AI coding agents via generated skill files — Claude, Cursor, Copilot, Gemini, Windsurf, Cline, and more. If your agent is on the list, OpenSpec integrates with zero configuration.

Low barrier to entry

npm install -g @fission-ai/openspec && openspec init and you're writing specs. No schema to learn, no required frontmatter. Designed to feel effortless — especially for brownfield codebases.

Clean change-delta model

OpenSpec's ADDED / MODIFIED / REMOVED format for evolving specs is well-designed. Each change is a folder with a proposal, delta specs, and tasks — a structured way to propose modifications.

Feature comparison.

Capability	OpenSpec	SpecScore
Spec format	Markdown (no frontmatter)	Markdown + YAML frontmatter
Spec linting	File structure only	Content quality — vague verbs, missing ACs, dangling refs
Requirement IDs	None (referenced by title)	Slug-based (`REQ: slug-format`)
Acceptance criteria IDs	None	Machine-addressable IDs
Lifecycle status	Implicit (file location)	Enforced — Draft → Under Review → Approved → Implementing → Stable → Deprecated
Code-to-spec traceability	None	`specscore:` annotations + `Verifies:` commit trailers
Sub-features	No	Yes (nested directories)
Cross-references	No formal mechanism	Dependencies, Source Ideas, plan references
CI integration	Basic (`openspec validate`)	`specscore lint` with configurable severity, pre-commit hooks
Agent support	29 agents	Claude Code primary + CLI for any agent
Schema customization	Yes (`schema.yaml`, fork/init)	Fixed schema (consistency by design)
Change proposals	Delta model (ADDED/MODIFIED/REMOVED)	Change-request ideas + proposals
Runtime dependency	Node.js 20.19+	None — single Go binary
License	MIT	MIT

Where SpecScore goes further.

Validation goes beyond file structure

OpenSpec's validate checks file structure — does the file exist, does it have the right sections. SpecScore checks more, in two layers: lint deterministically verifies content relationships — every requirement has acceptance criteria, cross-references resolve, status transitions are valid — and an AI reviewer (/review, /score) catches what no linter can: ambiguous criteria and vague verbs.

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ link  "Related Feature: discount-tiers" not found

Every requirement has a machine-readable ID

OpenSpec references requirements by title — fragile to renames. SpecScore assigns slug-based IDs (REQ: slug-format) and AC IDs that survive renames, refactors, and agent handoffs.

Lifecycle is enforced, not implied

In OpenSpec, a spec's lifecycle is its file location: specs/(current), changes/ (proposed), archive/ (done). In SpecScore, lifecycle is an enforced status field — Draft → Under Review → Approved → Implementing → Stable → Deprecated — validated by lint, transitioned by specscore change-status from git hooks or CI.

Code traces back to specs

OpenSpec has no traceability mechanism. SpecScore has specscore:source annotations in code comments and Verifies: commit trailers. Run specscore code refs and get a deterministic answer to "which code implements this requirement?"

No runtime dependency

OpenSpec requires Node.js 20.19+. SpecScore is a single Go binary — no runtime, no node_modules. Works in Go, Rust, Python, Java projects without adding Node to the toolchain.

Composable artifact hierarchy

OpenSpec specs are flat by domain. SpecScore has a typed hierarchy: Ideas promote to Features, Features contain Requirements and ACs, Plans reference ACs, Tasks reference Plans. All relationships are machine-navigable via the CLI.

When to use which.

Start with OpenSpec when…

You use Cursor, Copilot, or non-Claude agents and need out-of-the-box integration.
You're adding specs to an existing codebase for the first time and want zero friction.
Your team values schema flexibility over enforcement.

Use SpecScore when…

You need spec quality enforcement — lint catches ambiguity before agents waste tokens on it.
You need code-to-spec traceability — "which code implements this requirement?" returns a deterministic answer.
You're building a large system with many features, sub-features, and lifecycle transitions.
You want zero runtime dependencies — one binary, no Node.js required.
You need spec quality gates in CI — specscore lint exits non-zero on failures, same as ESLint or go vet.

They're not mutually exclusive.

SpecScore can lint OpenSpec's spec.md files. Teams that start with OpenSpec can add SpecScore's quality layer without migrating — lint the specs you already have, add traceability when you need it, enforce lifecycle when your team grows.

OpenSpec is a solid on-ramp. SpecScore is the guardrails.

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.