verify-by-exercising
Skill0 starsChanged 4 months agoMITView on GitHub
Verify a change by driving the affected flow end-to-end — run the command, hit the endpoint, render the page — not just typecheck or a green suite. Use before declaring any code change done.
In this repository32 other files it gives its agents.
- architect-modeSkill
- architecture-bundleSkill
- code-like-a-localSkill
- decision-making-guardrailsSkill
- decision-recordsSkill
- delivery-bundleSkill
- fable-modeSkill
- finish-the-turnSkill
- incident-response-playbookSkill
- launch-readiness-gateSkill
- lead-developer-modeSkill
- lead-with-outcomeSkill
- lean-tool-useSkill
- migration-refactor-safetySkill
- plan-before-implementationSkill
- pr-and-commit-hygieneSkill
- product-delivery-bundleSkill
- product-minded-engineer-modeSkill
- reliability-bundleSkill
- reliability-incident-modeSkill
- review-quality-gateSkill
- run-guardrails-on-code-changesSkill
- security-bundleSkill
- security-minded-engineer-modeSkill
- senior-operating-systemSkill
- staff-engineering-bundleSkill
- staff-engineer-modeSkill
- stakeholder-communicationSkill
- surgical-questionsSkill
- systematic-debuggingSkill
- test-disciplineSkill
- truthful-reportingSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
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
A CLI change: run the command with the flags the change affects and read its output.
- Distinctive: line 26
Verify at the outermost practical layer, not the innermost convenient one.
- Distinctive: line 33
Verify the closest layer you *can* reach, and name where verified stops and inferred begins.
- Distinctive: line 44
Do not declare a change done on typecheck or compile alone.
- Distinctive: line 45
Do not present a green suite as verification without knowing it exercises the change.
- Distinctive: line 46
Do not let "hard to run" quietly become "skipped" — name the gap.
- Distinctive: line 47
Do not describe expected behavior in words that imply you observed it.
≈ “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 by exercising the change
Compiling, typechecking, and even a green test suite tell you the code is plausible. Verification means observing the changed behavior actually happen. This is the gap where "done" claims most often turn out false.
What counts as verification
- A CLI change: run the command with the flags the change affects and read its output.
- An API change: hit the endpoint with a real request and inspect the response.
- A UI change: render the page or screen and look at it.
- A data change: query the before and after states and compare.
- A bug fix: rerun the original reproduction and watch it pass.
The common thread: you observed the new behavior, not a proxy for it.
Tests count only when they exercise the change
A green suite that never enters your changed code proves nothing about it. Before trusting a passing suite as verification, confirm at least one test actually drives the changed path — by adding one that fails without the change, or by checking that an existing test covers the exact branch you touched.
Drive the flow the user will use
Verify at the outermost practical layer, not the innermost convenient one. A unit test on the helper plus a real request through the route is strong; the unit test alone leaves the wiring — where most bugs live — unverified.
When you genuinely can't exercise it
Sometimes the flow needs credentials, hardware, or an environment you don't have. Then:
- Say plainly that the change is untested end-to-end and exactly why.
- Verify the closest layer you can reach, and name where verified stops and inferred begins.
- Tell the user the one command or click that would complete verification on their side.
An honest "untested past the unit level" is a fine report. An implied "works" is not.
Report what you observed
State the command you ran and the output you saw, not just the conclusion. "Ran curl localhost:8080/health — returns 200 with the new version field" is verification the reader can trust and repeat; "the endpoint works now" is a claim.
Non-negotiables
- Do not declare a change done on typecheck or compile alone.
- Do not present a green suite as verification without knowing it exercises the change.
- Do not let "hard to run" quietly become "skipped" — name the gap.
- Do not describe expected behavior in words that imply you observed it.
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.