verify
Skill3 starsChanged 19 days agoApache-2.0View on GitHub
Use before claiming any work is done, fixed, working, or passing, before saying a task or requirement is complete, and before committing or opening a PR. Requires running the check and showing its output as evidence.
188 other projects use a version of this.
Adopted by
Most recently taken up by
- Doist/todoist-aitheir own version, first seen Nov 9, 2026
- udecode/better-convextheir own version, first seen Nov 9, 2026
- pytorch/heliontheir own version, first seen Nov 8, 2026
- amir20/dozzletheir own version, first seen Nov 8, 2026
- Doist/todoist-clitheir own version, first seen Nov 8, 2026
- codewithmukesh/dotnet-claude-kittheir own version, first seen Nov 8, 2026
Used with
Projects with it also use instinct-export, instinct-import and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
TheKREATORSSkillinstinct-export
Export instincts from project/global scope to a file
Also in 3 projects that use this
- TheKREATORSSkill
instinct-import
Import instincts from file or URL into project/global scope
Also in 3 projects that use this
AviadPSkillrisk-assess
Assess the risk and blast radius of a proposed code change before implementing it. Evaluates CI impact, framework-wide vs localized scope, rollback path, and identifies blindspots. Use when user says "what's the risk", "is this safe", "assess the impact", "risk assess", "blast radius", or before applying framework-wide or CI-affecting changes. Do NOT use for code quality review (use code-quality) or plan validation (use design-validator).
Also in 3 projects that use this
diego-tobalinaSkillbuild-fix
Fix build and compilation errors systematically. Run when build fails.
Also in 6 projects that use this
AaravChadhaSkillsecure
Security review with a confidence gate - a finding exists only with a concrete exploit scenario and a high/medium/low confidence rating; everything else goes to a worth-hardening list, never inflated. Sweeps five surfaces: auth gates, secrets hygiene, injection and unsafe sinks, unsafe deserialization/crypto/transport, and LLM tool-use trust boundaries. Reports only, never fixes. Use when the user asks for a security review or to check vulnerabilities, secrets, or auth.
Also in 3 projects that use this
ArvorCoSkillspecify
Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec.
Also in 10 projects that use this
- +1 more from TheKREATORS
Other versions188 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 188
- react/react★ 252ksame name
- facebook/react★ 252ksame name
- garrytan/gstack★ 141ksame name
- oven-sh/bun★ 97ksame name
- anthropics/financial-services★ 41ksame name
- anthropics/financial-services-plugins★ 41ksame name
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- anthropics/claude-quickstarts★ 19ksame name
- NVIDIA-NeMo/Speech★ 19ksame name
178 more not listed
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 repository16 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- clarifySkill
- code-reviewSkill
- debugSkill
- designSkill
- exam-prepSkill
- fresh-eyesSkill
- music-studioSkill
- nutshellSkill
- planSkill
- repo-mapSkill
- shipSkill
- simplifySkill
- specSkill
- tddSkill
- writing-skillsSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 167 edited versions we read keep these.
3
Distinctive
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 14
Iron law: No completion claim without fresh evidence from after your last edit.
- Distinctive: line 19
Before any claim of success — including "Great!", "Done!", or moving on to the next task:
- Distinctive: line 24
If anything failed or could not be run, say so plainly.
“Common” is measured: kept by at least 6 in 10 of the 167 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Verify before claiming done
Iron law: No completion claim without fresh evidence from after your last edit.
"Should work", "looks right", and "I'm confident" are not evidence.
The gate
Before any claim of success — including "Great!", "Done!", or moving on to the next task:
- Identify the command or check that proves the claim.
- Run it now, in full. Not an earlier run, not a subset.
- Read the output: exit code, failure count, warnings.
- Report what you saw, with the command and the relevant lines.
- If anything failed or could not be run, say so plainly. "47/48 passing" is not "passing".
What counts as evidence
| Claim | Evidence | Not enough |
| Tests pass | Suite output with 0 failures, run after the last edit | An earlier run; "should pass" |
| Bug fixed | The original reproduction now behaves correctly | "I changed the code" |
| Regression test guards the fix | Revert the fix → test fails → restore → test passes | The test passing once |
| Build works | Build command exits 0 | Lint or type-check passing |
| Feature works | Exercised end to end (run the app, call the API, click the UI) | Unit tests alone |
| Requirements met | Re-read the spec or plan and tick each item against the code | "Tests pass, so it's done" |
| Delegated work is done | You read the diff or result yourself | The agent's own success report |
| Nothing else broke | The broader suite, and any test that was skipped or renamed is explained | Only the new test |
Also check
git difffor disabled, renamed, or skipped tests and for leftover debug code.- That the claim matches the request, not just the code: re-read what the user asked.
Rationalizations to reject
| Excuse | Answer |
| "It's a tiny change" | Tiny changes break builds too. The check is cheap. |
| "I ran it earlier" | You edited since. Run it again. |
| "The linter passed" | Lint is not behavior. |
| "I can't run it here" | Then say exactly what was not verified and why. |
| "Different wording, so the rule doesn't apply" | Any statement implying success needs evidence. |
Done when
- The proving command ran after the final edit, and its output is quoted or summarized faithfully
- Each requirement was checked against the code, not inferred from passing tests
- Anything not verified is named explicitly
Related: tdd, debug, ship, fresh-eyes.
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.