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
Ready-to-paste message
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-claimsOr download just the file:
curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/skills/dos-verify-done-claims/SKILL.md -o SKILL.mdTechnical 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:
registryorgrep-artifact— non-forgeable (a registry row, or an artefact/diff rung). This closes the claim.grep-subject(or baregrep) — 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 (rundos commit-auditon 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.
Popularity
- GitHub stars
- 48k
- Ranking position
- #4657
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
00-andruia-consultant
Helps your agent start or improve AI projects. It analyzes code, suggests tools, and creates action plans in Spanish.
sickn33/agentic-awesome-skills
007
Lets your agent perform security audits and threat modeling. It's useful for protecting projects against attacks and vulnerabilities.
sickn33/agentic-awesome-skills
10-andruia-skill-smith
Helps your agent create or improve AI tools. It defines how tools work, writes documentation, and validates the structure.
sickn33/agentic-awesome-skills
20-andruia-niche-intelligence
Lets your agent create a summary about a specific industry. It's useful for understanding the context, rules, usage patterns, and risks of a project, using reliable sources.
sickn33/agentic-awesome-skills
Similar skills
cpp-testing
Makes your agent write and improve tests for C++ code. It helps set up testing tools and fix errors.
affaan-m/ECC
csharp-testing
Helps your agent create tests for C# and .NET code. It uses best practices to ensure tests are efficient and reliable.
affaan-m/ECC
django-tdd
Enables your agent to apply testing strategies for Django with pytest-django and TDD. It's useful for writing robust tests and ensuring code quality, especially for DRF APIs.
affaan-m/ECC