| name | verification-before-completion |
| description | Before telling the user a coding task is done, actually verify it — build, run the relevant tests/linter, and confirm the change does what was asked with no regressions. Use whenever you are about to claim a change is finished, fixed, or working. |
Verify before you claim it's done
Saying "done" without checking is the most common way an agent ships a broken
change. Before you report a coding task as finished, fixed, or working, VERIFY
it — do not assume.
Checklist (do it, don't narrate it)
- Build / compile what you changed. If it doesn't build, it isn't done.
- Run the relevant tests with the project's own command (a
Taskfile/
Makefile target, go test, npm test, …). Run the narrowest command that
covers your change first, then the fuller suite if it's cheap. If the area you
changed has no test and the change is non-trivial, add one.
- Run the linter/formatter the project uses and fix what it flags.
- Re-read the request and confirm EVERY part is addressed — not just the
easy part. Check the edge cases and error paths you touched.
- Look for regressions — did the change break a caller, a contract, a test,
or a neighbouring feature?
Reporting
- Report what you actually ran and its result ("
go test ./... green, task lint 0 issues"), never "should work".
- If something failed, or you could not verify a part, SAY SO plainly — never
paper over a failure or a skipped step.
- If a test fails, fix the code (or the test, if the test was wrong) before
claiming done — don't hand back a red build.
A task is "done" only when you have evidence it works, not when the code looks
right.
