verify-before-done
Evidence rules for completion claims. Use before ticking an acceptance criterion, ending an implementation run, or writing anything that says something works, passes or is fixed.
SKILL.mdcatalog/agents/backend-developer/skills/verify-before-done/SKILL.md
GitHubVerification Before Completion
Overview
Claiming work is complete without verification is dishonesty, not efficiency.
Core principle: Evidence before claims, always.
The Iron Law
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in THIS run, you cannot claim it passes. A previous run, "should pass", or "looks correct" is not evidence.
The Gate Function
Before claiming any status or moving any task forward:
- IDENTIFY — what command proves this claim?
- RUN — execute the full command, fresh and complete.
- READ — the full output: exit code, failure count, warnings.
- VERIFY — does the output actually confirm the claim? If no: state the real status with evidence.
- ONLY THEN — make the claim, with the evidence.
Skipping any step is lying, not verifying.
What Each Claim Requires
| Claim | Requires | Not sufficient |
|---|---|---|
| Checks pass | The component's list_component_checks commands, run in this run, exit 0 — the hand-off gate runs exactly these |
A different command you picked yourself |
| Build succeeds | Build command: exit 0 | Linter passing, logs look fine |
| Bug fixed | Re-run the original symptom: passes | Code changed, assumed fixed |
| Regression test guards the fix | Revert the fix, run the test (MUST FAIL), restore, run again (passes) | The test passing once, with the fix already in place |
| Endpoint works (backend) | curl against the running service: status code and body |
Code review of the handler |
| Screen works (frontend) | browser_read_dom with contains: for the element, plus screenshots at the four widths |
A build that compiled |
| Screen works (mobile) | mobile_screenshot / mobile_read_ui, or the Flutter web-render fallback when no device is attached |
"The widget should render" |
| AC met | Line-by-line check of every acceptance criterion against what you just verified | Tests passing |
Tests passing is NOT the same as requirements met — re-read every acceptance criterion and confirm each one is actually satisfied.
Handoff
Then close as your prompt says: final message, no comment, no move.
If you cannot show fresh passing output, the task is not done — say what actually failed instead. And do not re-run a check you already have fresh output for: once a build has passed on the code as it stands, running it again proves nothing and costs the run.
Red Flags — STOP
- Using "should", "probably", "seems to"
- Expressing satisfaction before verification ("Done!", "Perfect!")
- Finishing a run without having run the checks in it
- Relying on partial verification ("the linter passed")
- Running the same check twice over unchanged code — that is not rigor, it is a loop
Rationalization Prevention
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification. |
| "I'm confident" | Confidence is not evidence. |
| "Just this once" | No exceptions. |
| "Partial check is enough" | Partial proves nothing. |
| "I'm tired / it's late in the task" | Exhaustion is not an excuse. |