dos-witness-claim
The `dos-witness-claim` skill intercepts subagent results at fold points and verifies claimed effects through independent read-backs rather than accepting narrated success. It shells `dos` verbs to witness shipped git phases, created files, database rows, and sent messages, folding only byte-author-confirmed outcomes back into the execution chain. Use this at `parallel()` barriers, pipeline synthesis steps, or any boundary where one agent's output becomes another agent's input, preventing eloquent false claims from propagating downstream.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernel /tmp/dos-witness-claim && cp -r /tmp/dos-witness-claim/src/dos/skills/dos-witness-claim ~/.claude/skills/dos-witness-claimSKILL.md
# dos-witness-claim — fold the witnessed effect, never the narrated one
> **This is the screenplay for the one move the whole substrate exists to make:**
> when a subagent hands you a result, the result is a *claim*, not a fact. A claim
> re-narrating the agent's own work is **consistency, not grounding** (docs/138).
> Belief is earned only by a read-back whose **byte-author is not the judged
> agent** (a fresh GET, a git existence check, an OS exit code, a state diff). This
> skill never decides ground truth itself — it shells `dos` verbs and reads the
> verdict. The kernel decides; the skill narrates.
The shape is domain-free: **discover the layout → classify the claim type →
witness it on a non-forgeable rung → fold ONLY confirmed.** The *policy* (which
lanes, which plan grammar, where state lives) is data the screenplay reads from
`dos doctor --json`, never literals it hardcodes.
**The seed-2 payoff.** This makes the worker's MODEL TIER irrelevant to trust. A
weak worker and a strong worker face the SAME witness gate: both have their
claimed effect re-read from a surface they did not author. A confident, fluent,
frontier-strength narration of a success the world does not corroborate is exactly
the silent fail this gate catches (docs/177) — and a weak worker that actually
shipped the effect passes it. Distrust is aimed at the *byte-author of the
evidence*, not at the worker's eloquence.
## Inputs
- A set of subagent **results** to fold (return strings + their transcript paths),
e.g. the children of a `parallel()` barrier or a `pipeline()` stage. A result is
the thing you are tempted to interpolate directly (`${result}`) — don't.
- For each result, the **effect it claims** (a `(plan, phase)`, a created file
path, a DB row key, a sent-message id). If the worker emitted no checkable
effect, that is a real outcome (NO_CLAIM), not a pass — see Step 2.
## Step 0 — Discover the workspace layout (one call)
Run the doctor verb and read the result. **This is the WCR on-ramp: every
path/lane/exit-code below comes from here, never a literal.**
```bash
dos doctor --workspace . --json
```
Parse the JSON object. The fields this skill uses:
- `exit_codes.verify` — `{shipped, not_shipped, contract_error}`. Branch on these,
never on parsing the prose, for the **git-phase** claim type (Step 3a).
- `exit_codes."verify-result"` — `{healthy, unreadable, dead, contract_error}`
(`dead=3`). Branch on these for the **terminal-state** witness (Step 3, the
prerequisite gate every claim type runs first).
- `paths.plans_glob` / `lanes` / `stamp` — the host's plan grammar and lane
taxonomy, if a claim names a `(plan, phase)`.
- `git` — if `false`, the git-existence witness (Step 3a) has no history to read;
every git-phase claim will be `source="none"`. Say so; do not silently pass it.
You may also read `admission_predicates` and `overlap_policy` here, but they are
not load-bearing for witnessing — they describe the arbiter, not the witness rung.
## Step 1 — For each result: is the worker even ALIVE? (the terminal-state gate)
**Run this BEFORE you read the worker's return string at all.** A return string is
worthless if the "worker" was a harness-synthesized death (a rate-limit / quota /
auth / server error the harness wrote and the worker never authored). ~32% of real
subagents return such a string (docs/197 §2), and it survives a naive
`.filter(Boolean)` to be banked as a finished finding.
```bash
dos verify-result --workspace . --transcript <agent-transcript.jsonl>
echo "exit=$?"
```
Branch on `exit_codes."verify-result"`:
- `3` **DEAD** — the terminal record was harness-authored (`message.model ==
"<synthetic>"`, the unforgeable authorship marker). **Do NOT fold this result.**
Route the worker's OWN unit for re-dispatch, and **count it in the denominator**
(a 4-of-7 fan-out is 4/7, never silently 7/7). The catch is grounding because it
read a DIFFERENT byte-author than the worker — the harness, not the model.
- `0` **HEALTHY** — a real terminal result; proceed to Step 2. (`0` also covers
**UNREADABLE**, the fail-safe floor: a read fault never fabricates a death. An
UNREADABLE result is *not* trusted as confirmed — it simply isn't classified
DEAD; its effect still must be witnessed in Step 3.)
- `2` — a contract error (no transcript). Fix the wiring; do not treat as HEALTHY.
This step is itself the cheap, shipped form of "byte-author ≠ judged agent": the
liveness of the worker is read from the harness's own authorship marker.
## Step 2 — Classify the claim TYPE (so you know which witness to ask)
For each HEALTHY result, decide what checkable effect it claims. **Extract the
claim at the boundary — abstain, never invent.** Free prose ("I'm done", "shipped
the auth work") yields NO claim: there is no honest way to derive the effect's
*identifier* from prose without inventing it (docs/134 §2.1). A claim you cannot
name is a **NO_CLAIM** — surface it for a human, do not manufacture one to witness.
Map each named claim to its witness rung:
| Claim type | What the worker asserts | Witness (byte-author ≠ agent) | Verb today |
|---|---|---|---|
| **git phase** | "(plan, phase) shipped" | git ancestry + ship-stamp grammar | `dos verify` (Step 3a) — SHIPPED |
| **terminal state** | the result itself is real | harness authorship marker | `dos verify-result` (Step 1) — SHIPPED |
| **created file / DB row / sent message / deploy** | "I created X / inserted row Y / sent Z" | a fresh GET / state-diff / OS exit / counterparty record | **NO CLI verb** (Step 3b) — Python API gap |
The first two are shipped CLI verbs. The third is the open seam — handled honestly
in Step 3b.
## Step 3 — Witness the claim on a non-forgeable rung
### Step 3a — git-phase claims: ask the truth syscall
For a `(plan, phase)` claim, never trust the worker's "I committed it" and never
grep commit subjects yourself:
```bash
dos verify --workspace . <PLAN> <PHASE> --json
echo "exit=$?"
```
Read the `Adjudicate a GitHub issue's "this is resolved" claim from witnesses the claimant didn't author — then close it carrying the evidence, or refuse with the typed gap. Use when an issue looks already-solved, after landing a fix that should have closed one, or to sweep open issues for silently-resolved ones.
Pick the next most important open GitHub issue this agent can actually complete, make its done-condition true, land it with witnesses (suite + parity + commit-audit), and priority-tag every issue touched along the way. Use when asked to "work the backlog", "complete the next most important issue", or to fix a specific issue number end-to-end.
Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.
Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/<codename> git tag on the same commit. Does NOT bump versions or build new artifacts.
One automatic plan-class lifecycle tick. Reads the DECLARED class set + transition list from the workspace `[lifecycle]` table (not a hardcoded taxonomy), evaluates each trigger, spawns a read-only JUDGE-rung adjudicator (the `dos.judges` seam — advisory, fail-to-abstain) to approve/defer each candidate transition, applies the gated transitions as plan-meta edits + one commit per cycle, and logs to the run archive. Failsafes (per-cycle cap, per-plan cooldown, a veto class) are `[lifecycle]` data; the judge content is a host `dos.judges` driver. Every path/class comes from `dos doctor --json`. Use to garden a plan portfolio's lifecycle automatically, judge-gated. The DOS lifecycle gardener (SKP Axis 5, docs/207 Phase 5c).
Run /dos-dispatch on a recurring cadence, alternating with /dos-replan when the backlog drains — the dispatch→replan→dispatch cycle. The continue/stop/next-mode decision is the kernel's typed loop decision, not inline prose: each iteration is classified (`dos gate`) into a verdict and the loop's counters (drained-twice, the unclear/dirty-zero breakers, the iteration cap) drive the next step. Several loops on disjoint lanes run concurrently, each taking its own lane lease via `dos arbitrate`. Driven entirely by `dos` verbs + the workspace's `dos.toml`. The DOS reference loop workflow (SKP Axis 5).
End-to-end plan-and-ship for one lane — snapshot the portfolio with /dos-next-up, take a lane lease via `dos arbitrate` so parallel dispatches don't collide, gate the empty case via `dos gate`, ship the packet, and archive the run under the configured run dir. Driven entirely by `dos` verbs + the workspace's `dos.toml`; names no host path, lane, or commit convention. Use when you want to plan and ship the next batch on one lane in a single command, with concurrency safety. The DOS reference dispatch workflow (SKP Axis 5).
Ground a "keep working until the goal is met" stop condition in a witness the agent did not author, instead of letting the agent self-certify "done". A harness goal/Stop-hook condition is normally checked by the model re-reading its OWN work — consistency, not grounding. This skill turns the operator's goal into checkable EFFECT claims and wires `dos hook stop` so the Stop is refused until git ancestry (a shipped phase) or an effect read-back corroborates the claimed effect. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use when you want a self-stopping agent (or a `/loop` worker) to be unable to declare a goal complete on its own say-so. The single-agent self-stop analogue of `dos-witness-claim`.