Speccle

Speccle — a Claude Code plugin

Coverage says it ran.
Speccle says it's defended.

Build features as vertical slices: you ratify the acceptance criteria, the skills build to them, and the deterministic speccle-oracle proves the tests would notice if the code broke. It never calls an LLM.

targets/checkout — speccle-oracle strength

open the demo →

Line coverage

100.0%

Oracle strength

95.7%

Survivors

2

BASKET-1100%Adding an item increments its quantity by exactly 1
BASKET-2100%Removing the last item leaves the basket empty
CHECKOUT-1100%Tax rounds half-up to 2dp per line item
CHECKOUT-2100%An empty basket totals zero
CHECKOUT-388%Checkout rejects a basket of more than 100 line items

The problem

Generated code, generated tests, one green tick. Review is the bottleneck.

A green suite proves nothing if the tests wouldn't fail when the code is wrong. Speccle moves your attention up to the spec — you ratify the acceptance criteria, nothing gets built until you do — and mechanically attests everything downstream. The skills hold the judgement; everything deterministic is delegated to the speccle-oracle CLI, which never calls an LLM.

The unit of work

The feature folder.

One directory owns everything a vertical slice needs, side by side: the acceptance criteria, the feature's language, the code, and the tests that defend it. A test claims a criterion by carrying its [KEY-n] token anywhere in its full name — that one convention is the thread everything downstream joins over.

src/checkout/

SPEC.md            ← criteria, each a stable [CHECKOUT-n] id
CONTEXT.md         ← the feature's language and decisions
checkout.ts
checkout.test.ts   ← tests claim criteria by carrying the token

The Speccle loop

01 / 07

Input

[human]

A feature, in any form.

Prose, a ticket, a half-formed idea — or existing code you want brought under governance. implement-feature takes the first three; carve-feature takes the last, deriving the spec from what the code observably does.

02 / 07

Draft

[agent]

SPEC.md + CONTEXT.md, in the feature folder.

One directory owns the whole vertical slice: acceptance criteria as H2 headings — ## [KEY-n] followed by one testable statement — with free-form bodies for rationale and edge cases, and a CONTEXT.md holding the feature's language and cross-criterion decisions.

03 / 07

Lint

[tool]speccle-oracle lint

Nine fixed rules over the criteria.

Structural rules police keys and ids; quality heuristics judge the heading statement only — weasel wording, compound criteria, unmeasurable outcomes. One severity, no configuration: a spec lints clean or it doesn't.

04 / 07

Ratify

[human]

The pause where you own the criteria.

Nothing gets built until you ratify the criteria. Every skill that drafts a criterion stops here — before the first test of a new slice, before a human-path test in strengthen, before a carved spec is claimed.

05 / 07

Build

[agent]

Tagged tests and green code, one criterion at a time.

A test claims a criterion by carrying its [KEY-n] token anywhere in its full name — one describe block claims every test inside it. The tracer criterion goes end-to-end first; done means lint clean, every criterion claimed, all tests green.

06 / 07

Measure

[tool]speccle-oracle strength

Mutation + coverage → the per-criterion heatmap.

strength joins the specs with a Stryker mutation report and a coverage summary into killed ÷ covered per criterion. A criterion below 100% always lists its surviving mutants — the exact code changes no test noticed — with line coverage alongside as the naïve baseline.

07 / 07

Route

[agent][human]

Every surviving mutant routed — never the score.

Each survivor is judged on what it breaks, not on what it does to the number. The routing decides who acts next: the agent when a criterion already promises the behaviour, you when the spec needs sharpening.

Machine path

A criterion already promises the behaviour the survivor breaks — a test gap. Write the killing test, re-run.

Human path

Nothing promises it — a spec problem. Draft a sharper criterion; you ratify it.

Equivalent mutant

No test could ever detect it. Annotated in the source — and rare.

The measure

Oracle strength, not coverage.

killed ÷ covered, per criterion: of the mutants a criterion's tests execute, the fraction the suite kills. Below is a real run over the repo's targets/checkout — 100% line coverage, and still two survivors. Each one is an exact code change no test noticed.

Line coverage

0%

the naïve baseline

Oracle strength

0%

killed ÷ covered mutants

Gap

4.3%

what coverage overstates

46 covered mutants: 44 killed, 2 survived — each survivor a change no test noticed

The plugin

Three skills. One deterministic oracle.

The skills drive the loop and hold the judgement; the oracle lints the specs and scores the tests. Trust comes from the tools, not the agent — and every skill that drafts a criterion stops for you to ratify it.

Find out what your tests would miss.

Clone the repo, link speccle-oracle onto your PATH, and add the plugin to Claude Code. TypeScript, vitest, and StrykerJS today.