Verify, Don't Trust
Skill1 starsChanged 4 months agoMITView on GitHub
Never treat a self-report, a just-created API response, or an immediate list/edge-endpoint read as proof something worked. Verify independently via a different path before marking anything done. Use before closing out a dispatched subagent task, any API write (Shopify/Meta/GitHub/etc.), or any 'merged cleanly' claim.
In this repository25 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- braindump-autoSkill
- braindumpSkill
- Capability Claim GroundingSkill
- Derived Figure AuditSkill
- design-review-loopSkill
- Dictation Garble CatcherSkill
- Discord Todo OpsSkill
- Full Account Security AuditSkill
- Large Task Session SplitSkill
- Personal Dashboard StyleSkill
- Pre-Push Secret ScanSkill
- Project Design DocSkill
- Public Repo Leak RetractionSkill
- repo-hygieneSkill
- Repo Index Drift CheckSkill
- Safe Section DeletionSkill
- Session HandoffSkill
- Skill Overlap AuditSkill
- superbraindumpSkill
- ui-change-visual-verifySkill
- Windows Process Restart (Safe)Skill
- Windows Shell Tool SelectionSkill
- Worktree Task-Pack VerificationSkill
- Zombie Process SweepSkill
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 21
If a "just-created" object doesn't show up in a list view, don't conclude it failed.
- Distinctive: line 23
3. Dispatched task "done" claims: Before accepting that a background task or subagent actually finished (or actually stalled):
- Distinctive: line 34
If the only evidence a thing worked is the tool call that just tried to make it work, that's not verification.
≈ “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
Verify, Don't Trust
The single most repeated lesson across this project's history: a report of success is not evidence of success. Every category below has produced a real, logged failure that this checklist would have caught before it shipped.
The four checks
1. "Merged cleanly" claims. A commit message saying a branch was merged is not proof.
git show -1 --format=%P <commit> # 2+ parent hashes = a real merge; 1 = it wasn't
git merge-base --is-ancestor <branch> <target> && echo "actually merged"Caught: a subagent's commit message claimed "merged v3-stage-1 first, no conflicts". It was a single-parent commit that never touched the target branch, and merging it as reported would have silently regressed an unrelated feature via an enum-slot collision.
2. API writes (Shopify, Meta, GitHub, any REST/GraphQL mutation). Never trust the create/update response alone, and never trust the first list/edge read after it. List endpoints are commonly eventually-consistent and lag behind writes by seconds to minutes.
- Re-fetch the created/updated object by its own direct ID before reporting success.
- If a "just-created" object doesn't show up in a list view, don't conclude it failed. Check by ID first.
3. Dispatched task "done" claims. Before accepting that a background task or subagent actually finished (or actually stalled):
git status --porcelain # real, uncommitted work sitting there = it finished, just didn't commit
git log -1 --format=%cd <path> # how stale is the last change, reallyCross-check against whether the process is still alive. Real completed-but-uncommitted work should be verified and finished, not treated as a failure and re-run from scratch.
4. Any temporary test-state seed. If you hardcode a value to force an otherwise-unreachable UI/code path into view for verification (a locked state, an error state, a specific data shape), always git diff after reverting the seed to confirm only the real feature diff remains. Never trust memory that "I definitely changed it back."
Rule of thumb
If the only evidence a thing worked is the tool call that just tried to make it work, that's not verification. It's an assertion. Read the state back through a second, independent path before calling it done.
See also
worktree-task-pack-verification: applies check #1 and #3 specifically to multi-task work dispatched across isolated git worktrees.
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.