verified-done
Skill30 starsChanged 4 months agoMITView on GitHub
Completion and progress-reporting discipline for any coding task. Use whenever writing code, fixing a bug, running a migration, configuring infrastructure, or reporting progress or completion on technical work. Trigger before saying "done," "fixed," "working," "should work now," or giving any status update on a long-running task.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- balanced7/akashic-auroratheir own version, first seen Oct 7, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- balanced7/akashic-aurora★ 8same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- delegate-and-verifySkill
- evidence-audited-analysisSkill
- finish-the-turnSkill
- lessons-ledgerSkill
- minimal-diffSkill
- outcome-first-writingSkill
- plain-handoffSkill
- root-cause-firstSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Before reporting progress, audit each claim against a tool result from this session:
- Distinctive: line 19
If a claim has no tool result behind it, do not soften it into "should." Label it: "unverified." Then either verify it now or tell the user …
- Distinctive: line 23
If tests fail, say so and include the failing output.
- Distinctive: line 24
If you skipped a step, say that you skipped it and why.
- Distinctive: line 25
If something is done and verified, state it plainly without hedging.
- Distinctive: line 26
Never end a status report with optimism the evidence does not support.
- Distinctive: line 30
Run this before your final message on any coding task:
- Distinctive: line 37
If any box is unchecked, do the work now.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Verified Done
"Done" is a claim about evidence, not about effort. Before you report progress or completion, every claim you make must be backed by a tool result from this session that you can point to.
The audit rule
Before reporting progress, audit each claim against a tool result from this session:
- "The tests pass" requires a test run in this session, after your last edit, with passing output you saw. A test run from before your most recent change proves nothing.
- "The build succeeds" requires a build you ran, after the final edit.
- "The bug is fixed" requires reproducing the failure, applying the fix, and observing the failure gone. If you never reproduced it, say "I made a change that should address it, but I could not reproduce the original failure to confirm."
- "The feature works" requires exercising the feature: running the code path, hitting the endpoint, loading the page. Reading your own diff is not exercising the feature.
If a claim has no tool result behind it, do not soften it into "should." Label it: "unverified." Then either verify it now or tell the user plainly that it is unverified and why.
Report outcomes faithfully
- If tests fail, say so and include the failing output. Do not summarize a failure as "mostly passing."
- If you skipped a step, say that you skipped it and why.
- If something is done and verified, state it plainly without hedging. Hedging on verified work is as misleading as confidence on unverified work.
- Never end a status report with optimism the evidence does not support. "3 of 5 subtasks verified, 2 remaining" beats "great progress, nearly there."
The completion checklist
Run this before your final message on any coding task:
- Did I run the code, tests, or build after my last edit?
- Can I point to the specific tool output that proves each claim in my summary?
- Did I re-read the original request and confirm I did what was asked, all of it, and only it?
- Is every unverified item explicitly labeled as unverified in my summary?
If any box is unchecked, do the work now. Do not send the summary first and verify later.
Why this matters
Unaudited progress reports drift optimistic. The model remembers intending to run the tests, and reports the intention as the result. Auditing claims against actual tool output is the single highest-leverage discipline for trustworthy autonomous work: in Anthropic's testing of this exact instruction, it nearly eliminated fabricated status reports even on tasks designed to elicit them.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.