dos-verify-done-claims

name	dos-verify-done-claims
description	Before accepting an agent's 'done / shipped / fixed' claim, verify it against ground truth (git ancestry + the commit's own diff) using the DOS kernel's `dos verify` and `dos commit-audit` — never the agent's own narration.
category	quality
risk	critical
source	community
source_repo	anthony-chaudhary/dos-kernel
source_type	community
date_added	2026-06-12
author	anthony-chaudhary
tags	["verification","git","ai-agents","trust","quality-gate"]
tools	["claude","cursor","gemini"]
license	MIT
license_source	https://github.com/anthony-chaudhary/dos-kernel/blob/master/LICENSE
plugin	{"targets":{"codex":"blocked","claude":"blocked"},"setup":{"type":"manual","summary":"Setup installs and executes an external PyPI CLI; keep out of plugin-safe bundles.","docs":"SKILL.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. The verdict is git-only and offline as used here; the one exception is dos verify in a workspace that wires a CI oracle, which --no-ci suppresses (see Security & Safety Notes).

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)

python3 -m venv .dos-venv
. .dos-venv/bin/activate
python -m pip install 'dos-kernel==<reviewed-version>'  # provides the `dos` CLI

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:

dos commit-audit --workspace . HEAD --json

commit-audit --json prints a JSON array of audited commits (one element even for a single HEAD), so read verdict from the first element — e.g. dos commit-audit --workspace . HEAD --json | jq -r '.[0].verdict'. (Without --json the same verdict prints as a one-line text row: , , or .) The verdicts are: (the diff backs the claim's ), (the subject's claim is not evidenced by the diff — treat the "done" as unproven), or . This judges the of change, never correctness — run the tests for that.