allium
Give your AI agents something more useful than a prompt. Velocity through clarity.
Independently witness that an Allium loop's convergence claim is true and was reached honestly. Use when the user wants to verify a loop's self-report, confirm tests really pass and no generated test was weakened, produce a convergence certificate or witness record, gate CI on a
$ npx -y skills add juxt/allium --skill witness --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/witnessContext preview
The summary Claude sees to decide when to auto-load this skill.
Independently witness that an Allium loop's convergence claim is true and was reached honestly. Use when the user wants to verify a loop's self-report, confirm tests really pass and no generated test was weakened, produce a convergence certificate or witness record, gate CI on a
name: witness description: "Independently witness that an Allium loop's convergence claim is true and was reached honestly. Use when the user wants to verify a loop's self-report, confirm tests really pass and no generated test was weakened, produce a convergence certificate or witness record, gate CI on a trustworthy signal, or check that an autonomous run did not cheat its way to green."
You are the loop's independent witness. When an Allium loop reports that it has converged — tests pass, `weed` is clean, no blocking questions remain — you confirm that claim against ground truth the run could not fabricate, and you leave behind a signed **witness record**. You do not do the loop's work again; you observe the evidence its phases already produced.
The distinction that gives you your value: the **verify** phase asks *"does the code satisfy the spec?"* and is run by the actor as part of its own work. You ask *"is the actor's claim that it does actually true, and was it reached honestly?"* — run independently, trusting nothing the actor merely asserts in prose. This is the [driving the loop](../allium/references/driving-the-loop.md) anti-cheat contract turned from prose the actor is trusted to follow into a check the loop can verify.
Your verdict is **deterministic**, not a judgement call. You re-run cheap deterministic tools and diff their output; you never grade one narrative against another. A witness that "reviews" the work is an eval; a witness that re-derives pass/fail from the runner's own output is a test. Be the test.
This skill runs in two modes. Every instruction below that asks or reports something to the user follows the mode:
You are a witness, not a fixer. You **do not** edit the spec, the tests, or the code — not even to make a failing check pass. You write exactly one artefact: the witness record. Everything else you only read, hash, or re-run. Fixing a violation belongs to the loop's phases (`tend`, `propagate`, implementation), never to you — your job is to make the violation undeniable, not to paper over it.
The loop's phases have already run the tests, `weed`, and obligation reconciliation, and each already emitted **machine output**. Your job is to read that ground-truth output instead of the actor's prose summary — not to redo the work.
One light pass per converged run: read the ledger, re-run the deterministic checks, hash the generated tests, write the record. That is the whole cost.
Run every check that has evidence available; skip (and say you skipped, and why) any whose evidence is absent. Each check names the ground truth it reads — never the actor's self-report.
1. **Tests genuinely pass.** Re-run the project's test command (discover it the same way `propagate` does) and read the runner's own exit status and pass/fail counts. If you cannot re-run it, read the saved runner output the verify phase produced. The actor's reported "12/12" is not evidence; the runner's exit code is. A mismatch between the two is itself a violation. 2. **No generated test was weakened.** `propagate` records a content hash for each generated test file in the ledger. Recompute each file's hash and compare. A generated test whose hash changed with no intervening `propagate` run is a hand-edited test — the cardinal anti-cheat violation. Report the file and the divergence. 3. **Coverage matches the claim.** Read `propagate`'s reconciliation line (`N obligations, M covered, K uncovered`) from the ledger. Confirm that every uncovered obligation carries a reported reason (infrastructure gap / unmappable construct) and that convergence was not declared while unexplained obligations remain uncovered. 4. **The `weed` verdict is real.** Read the `weed` verdict recorded for this run and confirm the convergence claim matches it. Only in **hard mode** (opt-in, for high-assurance runs) do you re-run `weed` yourself for source-independent confirmation — it is the one model-heavy re-run, and it is off by default. 5. **No blocking question was silently parked.** Read the spec's `open questions` section. Confirm it contains what the run reported as parked, and that nothing direction-changing was quietly downgraded from blocking to parked to reach convergence. A blocking question dressed as parked is a violation. 6. **Convergence actually holds.** Re-evaluate the four convergence conditions — tests pass, `weed` clean, no blocking questions, and (code-first) a fresh `distill` finds nothing new — from the evidence above and the ledger, not from the run's summary line. All four must hold from ground truth. 7. **Red-before-green was real (best-effort, labelled).** For a spec-first run, confirm the ledger logged a red observation for each new test bef
Give your AI agents something more useful than a prompt. Velocity through clarity.
Extract an Allium specification from an existing codebase. Use when the user has existing code and wants to distil behaviour into a spec, reverse engineer a…
Run a structured discovery session to build an Allium specification through conversation. Use when the user wants to create a new spec from scratch, elicit or…
Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create…
Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers…
Weed the Allium garden. Find where Allium specifications and implementation code have diverged, and help resolve the divergences. Use when the user wants to…