verification-before-completion

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)

1. Build / compile what you changed. If it doesn't build, it isn't done.
2. 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.
3. Run the linter/formatter the project uses and fix what it flags.
4. Re-read the request and confirm EVERY part is addressed — not just the easy part. Check the edge cases and error paths you touched.
5. 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.