Sp
Specter
toolchain · the compiler

tsc, but for specifications.

Specter validates specification files the way a type checker validates source code: parse, resolve dependencies, type-check constraints, measure coverage, gate CI.

$ specter sync
parseMalformed YAML52 ok
resolveCircular deps, refs0 err
checkOrphan constraints0 err
coverageTier-1 ≥ 100%100%
syncCI gate · mergePASS
✓ all specs in sync, merge unblocked

The pipeline

Five stages, each catching a different class of error

Specter treats .spec.yaml files as first-class artifacts in a dependency graph: authoritative, testable contracts the codebase is derived from.

01ParseMalformed YAML, missing required fields, schema violations~ Syntax errors
02ResolveCircular dependencies, broken references, version mismatches~ Linker errors
03CheckOrphan constraints (no coverage), conflicts, breaking changes~ Type errors
04CoverageAcceptance criteria without tests, tier-based thresholds~ Code coverage
05SyncFull pipeline as a CI gate: pass or fail the merge~ Build gate
Plus:specter watchspecter diffspecter doctorspecter explainspecter reversespecter init

Why it exists

When the AI writes the code, how do you know it built what you meant?

Natural-language prompts are ambiguous, and an AI fills the gaps silently and confidently. The code runs; the intent quietly drifted. Spec-driven development makes the contract explicit and machine-checkable:

“Every module has a spec. Every spec has acceptance criteria. Every criterion has a test. A compiler gates CI to enforce coverage. Here is the tool. Read it yourself.”

Verifiable
Anyone can run specter sync against the Kensa repo and see whether specs, tests, and code are in alignment.
Auditable
The CI pipeline's pass/fail history is a permanent record of spec coverage at every merge.
Machine-enforced
Not a process that depends on human diligence. The build fails if coverage drops below the tier threshold.

One pipeline, any contract

It validates the shape, not the category

A .spec.yaml can describe runtime behavior, data invariants, an API schema, an architecture rule, or a security policy. Specter checks that the spec is well-formed, that its references resolve, and that its acceptance criteria are covered, whatever the spec is about.

The same checks run in your editor and in CI: a VS Code extension surfaces coverage gaps and schema diagnostics inline, and specter sync is the merge gate.

Specter validates its own specs
5
specifications
33
acceptance criteria
37
tests
100%
coverage, all specs

Specter also validates Kensa's and OpenWatch's specs. The compiler that enforces coverage across every Hanalyx product is held to the same bar it enforces, and you can run it yourself to check.

For AI coding agents

As AI agents write more production code, the question shifts from “can the AI write it?” to “can anyone verify the AI wrote it correctly?” Specter is that verification layer.

The spec is the contract
The agent's input is the spec; its output is the implementation. Specter validates the spec is well-formed before the agent starts.
Coverage catches gaps
If the agent skips edge-case tests, the coverage stage fails the build. Missing tests must be added before the merge gate opens.
Drift is mechanical
If code and spec diverge, sync flags it. "Divergence is a bug" is enforced by a compiler, not human memory.

FAQ

Specter FAQ

What is Specter?

Specter is a compiler for specification files. It parses, resolves, and type-checks .spec.yaml files, measures coverage, and gates CI, the way a type checker validates code.

What is Spec-Driven Development?

Spec-Driven Development is a methodology where structured specification files are the single source of truth for every feature. The spec defines context, objective, constraints, and acceptance criteria before code is written; when the spec and the code disagree, the spec is right.

How does Specter fit into CI?

Specter runs in the pipeline (parse, resolve, check, coverage, sync) and can fail the build when specs are invalid or coverage falls below a threshold, so specifications stay enforced.

How is Specter different from OpenAPI?

OpenAPI describes HTTP API surfaces. Specter describes component contracts of any kind, such as runtime behavior, data invariants, security policy, or schema, with constraints and acceptance criteria, and it models dependencies between specs. The two are complementary.

Specs as code. Enforced by a compiler.