Skip to content
Skillpedia
Testing48k · #4657

dos-verify-done-claims

Helps your agent verify if code was actually fixed. It compares changes against history to be sure.

What it does

This tool checks if an AI agent's work is truly finished by comparing what it claims to have done against actual evidence in the code's history. It uses a system called the DOS kernel to ensure the work was actually done, not just stated.

When to use it

  • ✓When an agent says it finished a task and you want confirmation.
  • ✓After a code update, to confirm the description matches the changes made.
  • ✓When combining work from multiple parts, to verify each result individually.

Example of what to ask your AI

“Verify that the latest code update actually fixed the bug it claims to have fixed.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/sickn33/agentic-awesome-skills/blob/main/skills/dos-verify-done-claims/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/sickn33/agentic-awesome-skills/blob/main/skills/dos-verify-done-claims/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The tool uses specific commands from the DOS kernel system to look at the code's change history and the exact content of each modification. It compares the work description with what was actually changed in the code.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add sickn33/agentic-awesome-skills --skill dos-verify-done-claims

Or download just the file:

curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/skills/dos-verify-done-claims/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

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: · OK …, ⚑ UNWITNESSED …, or · abstain ….) The verdicts are: 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:

dos verify --workspace . PLAN PHASE --json --no-ci

--no-ci keeps the verdict git-only (see the Security note below). With --json you get the shipped and source fields. (The default text form prints SHIPPED PLAN PHASE (via grep) or NOT_SHIPPED PLAN PHASE (via none) — the same verdict, and the process exit code is non-zero when not shipped.)

Grade shipped: true by the source, because git fallback grades itself by forgeability — and forgeable evidence is exactly what this skill exists to distrust:

  • registry or grep-artifact — non-forgeable (a registry row, or an artefact/diff rung). This closes the claim.
  • grep-subject (or bare grep) — forgeable: a commit subject or body carried the phase token, which an agent can write without doing the work (even on an empty commit). Treat this as shipped-per-the-subject, not confirmed — corroborate it (run dos commit-audit on that commit, below) before you close.
  • none — no positive evidence; accept as "not shipped", not as a tool failure.

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

# The agent committed and said it's fixed. Check the diff backs the claim.
# commit-audit --json returns an array, so read the first element's verdict:
dos commit-audit --workspace . HEAD --json | jq -r '.[0].verdict'
# OK                -> the change is of the claimed kind; now run the tests
# CLAIM_UNWITNESSED -> the commit doesn't do what it says; reject

Example 2: confirm a feature phase shipped before closing a ticket

…

FAQ

What does 'forgeable' mean?

It means something can be easily changed or invented. For example, the description of a code change can be written by anyone, but the code itself cannot be altered without leaving a trace.

Does this tool check if the code is correct?

No, it checks if the change the agent said it made actually happened and was recorded in the code history. Code correctness should be verified by tests.

What should I do if the tool says the work is unproven?

It means there isn't enough evidence to confirm the work was done. The agent should be asked to redo it or provide more information/evidence.

Details

Original description by the author

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.

repo: sickn33/agentic-awesome-skills

Popularity

GitHub stars
48k
Ranking position
#4657
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills