dos-verify-done-claims
**dos-verify-done-claims** uses the DOS kernel's deterministic `dos verify` and `dos commit-audit` commands to confirm completion claims against git history and actual diffs rather than agent self-reports. Use this skill immediately after commits or task completion to verify that a claimed effect (fix, feature, test pass) is actually evidenced in the repository's ancestry and file changes, catching mismatches between commit messages and actual modifications before building on supposedly finished work.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernel /tmp/dos-verify-done-claims && cp -r /tmp/dos-verify-done-claims/listings/antigravity-skill ~/.claude/skills/dos-verify-done-claimsSKILL.md
# Verify done-claims against ground truth, not the agent's word ## Overview When an AI agent says "done", "shipped", or "fixed", that is a **claim**, not a fact — and a claim the agent checks by re-reading its own work is *consistency, not grounding*. This skill replaces that self-report with a verdict from a witness the agent did not author: it shells the **DOS kernel** (`dos verify`, `dos commit-audit`) to confirm the claimed effect from git ancestry and the commit's actual diff. DOS is deterministic — no API key, no LLM, no network. This skill adapts the DOS reference "witness-claim" pattern (`anthony-chaudhary/dos-kernel`) into a host-agnostic screenplay. ## When to Use This Skill - Use when an agent reports a task/phase/feature as **complete** and you want that "done" confirmed from evidence before building on it. - Use right after a commit, to confirm the commit's **message matches its diff** (catch a `fix:` that only touched a README, or a "tests pass" that deleted the assertions). - Use when folding many sub-agents' results — verify each claimed effect instead of trusting the return string. - **Do not** use it to judge whether code is *correct* — that is what the test suite is for. This skill checks did-the-claimed-thing-actually-ship. ## How It Works ### Step 1: Install the kernel (once) ```bash pip install dos-kernel # provides the `dos` CLI; deterministic, no key ``` ### Step 2: Audit the latest commit's claim vs its diff A commit subject is forgeable (whoever wrote the message authored it); the files it touched are not (git did). `dos commit-audit` grades the subject against the actual diff: ```bash dos commit-audit --workspace . HEAD ``` Read the `verdict` field: `OK` (the diff backs the claim's *kind*), `CLAIM_UNWITNESSED` (the subject's claim is not evidenced by the diff — treat the "done" as unproven), or `ABSTAIN`. This judges the *kind* of change, never correctness — run the tests for that. ### Step 3: Verify a named phase actually shipped If the agent claims a specific plan/phase landed, confirm it from git history rather than the transcript: ```bash dos verify --workspace . PLAN PHASE ``` `shipped: true` with a `source` of `registry` or `grep` is real evidence; `source: none` means there is no positive evidence — accept that as "not shipped", not as a failure of the tool. ### Step 4: Fold only confirmed effects Accept the agent's "done" **only** when Step 2/3 corroborate it. If `CLAIM_UNWITNESSED` or `shipped: false`, the work is not done regardless of how confidently the agent narrated it — send it back. ## Examples ### Example 1: gate an agent's "I fixed the bug" claim ```bash # The agent committed and said it's fixed. Check the diff backs the claim: dos commit-audit --workspace . HEAD # verdict OK -> the change is of the claimed kind; now run the tests # verdict CLAIM_UNWITNESSED -> the commit doesn't do what it says; reject ``` ### Example 2: confirm a feature phase shipped before closing a ticket ```bash dos verify --workspace . AUTH AUTH2 # shipped: true, source: grep -> a real ship commit exists; safe to close # shipped: false, source: none -> no evidence; keep the ticket open ``` ## Best Practices - ✅ Run `dos commit-audit HEAD` immediately after every agent commit. - ✅ Treat `source: none` / `CLAIM_UNWITNESSED` as "not done", not as a tool error. - ✅ Keep the test suite as the separate correctness gate — this skill checks shipping, not correctness. - ❌ Don't accept a "done" because the agent's prose was confident. - ❌ Don't use this to replace code review or testing. ## Limitations - This skill does not replace environment-specific validation, testing, or expert review. - It checks whether a claimed change *shipped* / matches its diff — not whether the code is *correct*. - `dos verify` reads git history; in a repo with no commits there is nothing to witness (it will honestly report `source: none`). - Stop and ask for clarification if required inputs (a git repo, the `dos` CLI) are missing. ## Security & Safety Notes - This skill runs shell commands: `pip install dos-kernel` and the read-only `dos` verbs (`dos commit-audit`, `dos verify`). The `dos` verbs only **read** git history and the working tree — they do not mutate the repo, push, or network. - `pip install dos-kernel` installs from PyPI. The distribution name is `dos-kernel` (the bare `dos` on PyPI is an unrelated package — do not install it). Pin a version in locked environments. - Run in the repository you intend to adjudicate; the `--workspace .` argument scopes every verdict to that repo. ## Common Pitfalls - **Problem:** `dos verify` returns `source: none` and it looks like a failure. **Solution:** That is the honest "no evidence" verdict — it means the phase has no ship commit, so the claim is unproven. Re-stamp the real commit or keep the task open. - **Problem:** Installing the wrong package. **Solution:** The PyPI name is `dos-kernel`, not `dos`. ## Related Skills - The upstream DOS reference screenplays (`dos-witness-claim`, `dos-goal-gate`) in `anthony-chaudhary/dos-kernel` cover the multi-agent fan-out and self-stopping-agent variants of this same witness discipline.
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`.