/verification-before-completion
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.
$ npx -y skills add duckbugio/flock --skill verification-before-completion --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/verification-before-completion
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
verification-before-completion.SKILL.mdname: 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.
Read more
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.
Run a Claude Code AI dev team on your server and drive it from chat. Describe a feature in Telegram or VK; the team plans it, builds it on a branch, tests it, reviews it, and opens a PR — each chat in its own isolated workspace.