Skip to content
AI & Agents
Skill

/witness

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

From plugin
allium
4897 skills5 agents2 hooks
Install
$ npx -y skills add juxt/allium --skill witness --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/witness

Context 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

SKILL.md

witness.SKILL.md
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."

Witness

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.

Interaction modes

This skill runs in two modes. Every instruction below that asks or reports something to the user follows the mode:

  • **Interactive** — running inline in a conversation. Present the verdict and its violations directly, and ask the user how to route any failure.
  • **Non-interactive** — running as the `witness` subagent (for example at the Allium loop's convergence gate), where no user is reachable. Never wait for an answer: write the witness record, return the verdict and every violation with its routing in your final output, and let the caller act on them.

What you never do

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.

Cost discipline (why the witness is cheap)

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.

  • **Re-run freely: the cheap deterministic tools.** The project's test command, `allium check` / `allium analyse`, file hashing, and `grep` cost no model reasoning — they are fast, deterministic Bash calls whose output is small. Re-running the test command once to read the runner's own exit status is the strongest possible evidence and is not expensive.
  • **Never re-run: the model-heavy phases.** Do **not** re-run `propagate` (regenerating tests), `distill` (re-reading the codebase), or `weed`'s full alignment reasoning. Read the artefacts and summary lines they already produced. Re-doing an LLM phase is what would double the loop's cost — and it is exactly what a witness never needs to do.

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.

The checks

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

Read more
Ships withallium

The specification language that talks back: allium-lang.org.

Get the whole plugin
Stats
489
Stars
25
Forks
Active
Maintenance
JavaScript
Language
MIT
License
20d ago
Last commit
7mo ago
Created

Repo: juxt/allium

Other skills on allium.

distill
Skill

distill

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…

@juxt@juxtView Skill
elicit
Skill

elicit

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…

@juxt@juxtView Skill
propagate
Skill

propagate

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…

@juxt@juxtView Skill
tend
Skill

tend

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…

@juxt@juxtView Skill
weed
Skill

weed

Weed the Allium garden. Find where Allium specifications and implementation code have diverged, and help resolve the divergences. Use when the user wants to…

@juxt@juxtView Skill