SKILL.md
Verification Before Completion
Claiming work is complete without verification is dishonesty, not efficiency. The rule: no completion claim without fresh verification evidence, produced in this message, from the full command.
The gate
Before any status claim or expression of satisfaction:
- Identify the command that proves the claim.
- Run it, fresh and complete. Not a cached result, not a partial subset.
- Read the full output. Exit code. Failure count. Warnings.
- Compare output to claim. Output confirms it: state the claim with the evidence. Output does not: state the actual status with the evidence.
- Only then speak.
Skipping any step is not a shortcut. It is asserting something you do not know.
What each claim requires
| Claim | Requires | Not sufficient |
|---|---|---|
| Tests pass | Fresh test run, 0 failures in output | Earlier run, "should pass" |
| Linter clean | Full lint run, 0 errors | Partial file check |
| Build succeeds | Build exit 0 | Lint passing, logs "look good" |
| Bug fixed | Original symptom re-tested, gone | Code changed, fix assumed |
| Regression test works | Red-green cycle: fails on reverted fix, passes restored | Test passing once |
| Subagent completed | You checked the VCS diff yourself | The agent's "success" report |
| Requirements met | Line-by-line checklist against the spec or plan | Tests passing |
The regression-test row deserves emphasis: a test that has never failed proves nothing. Revert the fix, watch it fail, restore, watch it pass.
Scope of the rule
It covers every phrasing that implies success: "done", "fixed", "should work now", "looks good", "Perfect!", paraphrases, and implications. Changing the wording does not change the obligation. It applies before commits, PRs, task completion, moving to the next task, and reporting upward after delegation.
Good vs bad
Bad: "I've fixed the auth bug and added a regression test. Should be good to merge!" No command was run in that message. Two claims, zero evidence.
Good: "Ran npm test: 87/87 passing. Reverted the fix and re-ran the new test: fails with 'expected 401, got 200', so it catches the bug. Restored: passes. Ready to merge."
Verification
This skill is its own check. Before sending any message containing a success claim, scan the message for the evidence beside the claim: the command and the decisive line of its output. Expect every claim to have both. If one does not, either run the command now or rewrite the claim as what you actually know ("code changed, not yet verified").
Completion checklist
- [ ] Every claim in the outgoing message maps to a command run in this session
- [ ] Full output read: exit code and failure counts, not just the tail
- [ ] Regression tests proven with a red-green cycle
- [ ] Subagent reports checked against the actual diff
- [ ] Requirements walked line-by-line, gaps reported as gaps
Any box unchecked: not done. Fix or say so.
Footguns
- Stale evidence. A test run from before your last edit proves nothing about the current code. Any edit invalidates all prior runs; re-run.
- Partial verification extrapolated. One passing file does not verify the suite; a green linter does not verify compilation. Match the command to the claim's full scope.
- Trusting delegation reports. Subagents report success optimistically. The diff and a fresh test run are the ground truth, every time.
Red flags
If any of these appear in your draft message or your head, stop and run the command:
- "Should work now"
- "I'm confident this fixes it"
- "Linter passed, so we're good"
- "The agent said it succeeded"
- "Just this once, it's a trivial change"
- "I'm tired and this is obviously right"
- "Great! Done!" (before any command ran)
There is no wording that exempts a claim from evidence. If the verification command did not run in this message, the claim does not go in this message.