kmshihab7878 Verification Before Completion
No "done" without evidence. No "works" without proof. No "correct" without output.
Triggers
- About to claim a task is complete, done, or finished
- About to assert code works, is correct, or functions properly
- About to say "should work", "looks good", "probably fine"
- End of any implementation, fix, or modification task
HARD GATE: Evidence Required
Before claiming completion, you MUST:
- Identify the claim you are about to make
- Execute verification (run tests, run the code, check the output)
- Read the output completely — do not skim
- Confirm match between expected and actual behavior
- Assert with evidence — quote the output that proves correctness
Banned Phrases
These phrases are never acceptable without accompanying evidence:
| Banned Phrase | Required Replacement |
|---|---|
| "should work" | "works — here's the output: [output]" |
| "probably fine" | "verified — test results: [results]" |
| "looks correct" | "confirmed correct — [evidence]" |
| "I believe this fixes" | "this fixes — reproduction no longer triggers: [output]" |
| "this should handle" | "handles correctly — tested with [input], got [output]" |
| "the tests should pass" | "tests pass: [test output]" |
| "I think we're done" | "done — all checks pass: [evidence]" |
Verification Types
Match your verification to the claim:
| Claim Type | Required Verification |
|---|---|
| "Bug is fixed" | Show the bug no longer reproduces + tests pass |
| "Feature works" | Show test output covering happy path + edge cases |
| "Refactor is safe" | Show all existing tests still pass |
| "Build succeeds" | Show build output with zero errors |
| "No regressions" | Show full test suite output |
| "API works" | Show request/response with expected status codes |
| "Config is correct" | Show the system using the config successfully |
5-Step Protocol
Step 1: IDENTIFY — What claim am I about to make?
Step 2: EXECUTE — Run the verification (test, build, lint, etc.)
Step 3: READ — Read the FULL output, not just the last line
Step 4: CONFIRM — Does the output match the expected behavior?
Step 5: ASSERT — State the claim WITH the evidence
Integration
- Complements
confidence-check(pre-work) — this is the post-work counterpart - TDD's GREEN phase naturally produces verification evidence
- Debug's VERIFY step (Step 4) feeds into this skill
- Branch finishing requires verification before merge/PR
What Counts as Evidence
Acceptable evidence:
- Test output showing pass/fail results
- Command output showing expected behavior
- Error-free build/lint/type-check output
- Screenshots or logs showing correct runtime behavior
- Git diff showing the change + test output showing it works
NOT acceptable evidence:
- "I read the code and it looks right" (code review is not runtime verification)
- "This pattern always works" (appeal to authority is not evidence)
- "I tested it mentally" (mental models miss runtime behavior)