uscha.dev
a spec-driven methodology for LLM coding agents

You bring the idea.
The method builds the rest.

Uscha is a spec-driven, tool-agnostic methodology for developing with coding agents. No ceremony where it isn't earned — rigor where the stakes justify it. Its central mechanism: a deterministic ledger that separates what was measured from what was narrated.

The agent executes · the method governs · evidence decides · the human approves.

$ npx --yes @andresmassello/uscha@latest install --target claude
kit v1.50.1 MIT license Python 3.8+ · zero dependencies 9 skills Claude Code · Codex
the problem

The agent says it's done. Who contradicts it?

An agent will tell you the tests pass. It will tell you the feature is done. It is often right — and when it is wrong, you find out in production.
the two paradigms

Open loop vs. measured graph

There are two ways to put an agent to work on code. In the open loop, the agent decides the path and asks itself whether it is done — nothing outside it can contradict it. In the measured graph, the human defines the possible paths and every gate is answered by measured evidence, not the agent.

Open loop
The agent decides the path
  • investigate
  • modify code
  • run tests
  • review the result
  • solved?
  • done — or try again
Measured graph
You define the possible paths
  • reproduce the bug
  • does it reproduce?
  • find root cause · attempt fix
  • do the tests pass?
  • review
  • approved by a human?

Uscha is that measured graph, with two twists of its own: every gate is answered by a deterministic, auditable artifact — the ledger, the gates, coverage, the golden suite — and the loop does not vanish: it is caged inside a bounded convergence node that either converges or escalates to a human.

The open loop gives you an agent that believes it is finished. Uscha gives you an agent that cannot finish until the evidence permits it and a human approves it.

Read the full essay: why uscha exists →

The rule that orders everything

Gates that read FACTS block; those that GUESS over prose advise.

the spine

Five rules. Nothing more — and nothing less.

01

No code without SPEC + ACCEPTANCE

Before anything is built, what is being built exists — and so does how you'll know it's right.

02

The truth lives in versioned files

Not in the chat. SPEC.md, ADR, ACCEPTANCE.md, QA-LEDGER.json — all in the repo.

03

The human always approves the merge

The pipeline stops at the merge gate. Always. No exceptions.

04

Tests must assert

The gate is never weakened to make it pass. A test that doesn't assert is not a test.

05

Migrations anchored with a golden

Old behavior is captured mechanically before touching it. The agent never authors the .approved.

the trail

From idea to production, with gates along the way

idea discovery spec adr / constitution build qa loop verify human gate production
measured gate human approval
the kit

Nine skills covering the full cycle

From the opening interrogation to the status dashboard. Each skill does one thing; the ledger ties them together.

/uscha-discovery

From a bare idea to a spec package: the skill interrogates until a shared shape of the system exists, writing the documents as it goes.

/uscha-adr-refine

Interview, then distill: the same interview applied to a feature you already know. Not a generator — an interrogator.

/uscha-devloop

The build + QA orchestrator: a disciplined cycle, every step in the ledger, and a hard stop at the human merge gate.

/uscha-characterize

Freeze current behavior as field truth: the golden suite — the one artifact the agent must not author.

/uscha-reverse-discovery

The inverse of discovery, for brownfield: nothing is invented — facts are extracted from the existing system, as a map + golden.

/uscha-rubric

The ACCEPTANCE of the non-testable: grades the change against a versioned RUBRIC.md. Advisory by default.

/uscha-mirador

Real status at a glance: readiness, sub-scores, phases, invariants and QA loops. The skill wires — it never computes.

/uscha-sysdoc

The system deck in two tracks — commercial and technical — with real metrics from the ledger. An optional report, on request.

/uscha-status

The statusline on demand: a one-line progress readout, for surfaces where the statusline isn't visible.

the library

Go deeper: the full documentation

Everything below is generated from the same repo the kit ships from — the docs and the code travel together.

the engine's numbers

Measured beats narrated — here too

29
engine subcommands
11
language stacks
9
skills in the kit
0
runtime dependencies
100%
Python stdlib

The engine is qa_ledger.py: pure Python, no pip installs. It ingests evidence from maven, gradle, ant, python, node, go, rust, dotnet, cpp, swift and flutter, and records it in QA-LEDGER.json — a deterministic ledger that records what was measured, never what was claimed.

Field note · real case 001
"Check" is a question. The agent answered with a commit.

A human asked the agent to "check" some remote QA errors. The agent diagnosed them well — and in the same turn, without showing the diagnosis or waiting for a reply, it announced "design closed", edited tests and production code, and ran the build. Between the question and the modified code: zero human decision points. The execution was competent; the failure was governance. That is exactly the hole Uscha exists to close.