verifying-before-claiming
Skill0 starsChanged 46 days agoMITView on GitHub
Use when about to say work is done, fixed, passing, or ready, or before committing, opening a PR, or moving to the next task
In this repository13 other files it gives its agents.
- debugging-systematicallySkill
- delegating-to-subagentsSkill
- executing-plansSkill
- finishing-workSkill
- investigating-in-parallelSkill
- isolating-workspacesSkill
- planning-workSkill
- receiving-reviewSkill
- requesting-reviewSkill
- shaping-designsSkill
- testing-firstSkill
- using-tackleSkill
- writing-skillsSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
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
Trivial: run the one check that proves the change, e.g.
- Distinctive: line 24
If you're about to write "should work", "looks right" or "probably fixed", that's a sign the check hasn't run yet.
- Distinctive: line 45
Every success claim in your message is backed by evidence produced after the last change, and every unverified part is labelled.
≈ “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
Verifying Before Claiming
A claim of success is only as good as the evidence behind it. Unverified claims cost the user more than an honest "not checked yet": they build on the claim, and the failure turns up later, when it's harder to trace.
Scale it
- Trivial: run the one check that proves the change, e.g. build or lint the touched file.
- Small / Substantial: match every claim to fresh evidence, below.
How
For each claim you're about to make:
- Identify the proof. Which command or observation would show it's true?
- Run it now, in full. An earlier run from before your last change doesn't count.
- Read the output: exit code, failure count, warnings.
- Report what it shows, with the evidence. If it contradicts the claim, report the actual state instead.
If you're about to write "should work", "looks right" or "probably fixed", that's a sign the check hasn't run yet.
| Claim | Evidence | Not enough |
| Tests pass | Test run: 0 failures | An earlier run, "should pass" |
| Build works | Build exits 0 | Linter passing |
| Bug fixed | Original symptom re-tested | Code changed |
| Regression test works | Seen failing without the fix, passing with it | Passes once |
| Subagent finished | You read its diff and ran its check | Its report |
| Requirements met | Each requirement checked against the result | Tests green |
When you can't verify
Say so plainly: what you couldn't run, why, and what the user should check. "Implemented but untested because there's no test database here" is useful. Implying success isn't.
Skip or shorten when
- The user explicitly waives verification. State once what hasn't been checked.
Done means
Every success claim in your message is backed by evidence produced after the last change, and every unverified part is labelled.
Next
finishing-workrequesting-reviewfor substantial or risky changes
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.