Checkwright

Reproducible checks that catch unsupported claims in coding-agent delivery before merge: a task marked done with no recorded test run, a skipped lifecycle stage, a spec naming a file the tree lacks. They prove the evidence a claim rests on exists, not that the code is correct.

It is for the maintainer of a repository coding agents write most of, who has to answer at merge time whether the work is actually done and cannot answer it by reading every diff.

It complements the workflow you already run. Keep your spec process, your prompts, your harness. Add Checkwright where a claim has to be mechanically proven rather than asserted: the instructions shape, the gates enforce. Why that split is the whole design: Positioning.

Try it first

demo runs the whole arc in a scratch repository of its own and removes it, without touching yours; what it does and what it needs first: Try it first.

curl -fsSL https://checkwright.dev/install.sh | sh -s -- demo                  # macOS and Linux

& ([scriptblock]::Create((irm https://checkwright.dev/install.ps1))) demo      # Windows, in PowerShell

npx checkwright demo                                                           # with Node

Install

From your repository’s root, in a new project or an existing one with every change committed, the same three routes without demo install the kits as one commit, the first two from the Release tarball:

curl -fsSL https://checkwright.dev/install.sh | sh                             # macOS and Linux

irm https://checkwright.dev/install.ps1 | iex                                  # Windows, in PowerShell

npx checkwright init                                                           # with Node

Per-system prerequisites, profiles and the other verbs: Install and upgrade.

What that buys you

Before. A session finishes a task, moves it to Done and stamps the iteration validated and closed; the evidence is the session’s own say-so. The commit goes in green, and the next stateless session reads it as ground truth.

After. The battery reds on the claim. This is demo’s third act as it prints, trimmed of its remedy, help and spec text:

  An agent reports task add-login-page done: it moves the task to Done and stamps
  validate and close for iteration first-release, but no test run was ever recorded.

  | ===== check-evidence-manifest =====
  | EVIDENCE-MANIFEST: 1 issue(s) coupling .workflow/validate-evidence.txt to .workflow/WORKFLOW-STATE.txt:
  |   iteration 'first-release' has a validate stamp but no evidence line — validate ran and recorded nothing
  |   FAIL: check-evidence-manifest (exit 1)
  → caught. Registered as a hook, this would have refused the commit.

Nothing there is a review opinion. Each finding is cheap and mechanically decidable, which is what earns it the right to block a commit rather than open a thread; the semantic residue stays with the human or the agent, undiluted.

That is what verification under delegation means, and it is the prerequisite for scaling agent orchestration past the point where a human reads every hop: coordination is only worth parallelizing once each coordinated result is checkable.

Which harnesses it runs under, and what adapts to yours: the tiered compatibility claim.

Start here

1. Why Checkwright — the delivery-methodology essay: what goes wrong when agents write, and the shape of the remedy.
2. Value — what each kit enforces set against what it costs your context budget, joined from the registries; drills down to the enforcement map and the footprint.
3. Coupling graph — which content surfaces each gate binds together, emitted from the per-gate manifests.
4. Roadmap — where the project is heading and what moves an item.
5. Announcing Checkwright — the launch note.

The kits

Each kit has its own page under Kit Reference in the navigation, which glosses every kit in one line. gate-sdk is the base every other kit runs on, and beyond it the checks and the workflow install without each other (What you install).

Positioning

Where Checkwright sits against practices you may already run, one page per angle.

• Where Checkwright sits — the layer model: Checkwright as layer-4 content beneath a closed harness prompt, plus its tiered harness-compatibility claim and memory-off position.
• Domain-driven design — Checkwright as the enforcement layer for a ubiquitous language: banned synonyms, comment and naming directives, and one home per definition.
• Agent orchestration — Checkwright as the evidence checks beneath a coordination framework: the gates, budget guard, stage stamps, and evidence manifest that make delegated work’s claims checkable.