"MUST load after making code changes and before claiming done. Run the project build/test command and confirm exit 0 before any completion claim, commit, or push. If verification fails, use the diagnostic output to fix the problem and re-verify. Triggers: editing source files, writing code, modifying config, making changes, implementing features, fixing bugs."
Install
npx skillscat add sebnow/configs/verification-before-completion Install via the SkillsCat registry.
Verification Before Completion
Core principle: Evidence before claims, always.
When To Apply
MUST apply before:
- Any commit or push operation
- Any completion claim ("done", "finished", "complete", "fixed")
- Any summary of completed work to the user
- Moving to the next task after finishing one
Verification Protocol
Before claiming any status:
- Detect: What build/test command does this project use?
- Run: Execute the command (fresh, complete)
- Read: Full output, check exit code, count failures
- Confirm: Does output confirm success?
- If yes: State result with evidence. Proceed.
- If no: Read the diagnostic output. Fix the problem. Re-run from step 2.
- If tool unavailable: Stop and tell the user.
- Only then: Make the claim, commit, or declare done
Skip any step = no claim permitted.
When Verification Cannot Run
If the verification command is not available in the environment
(e.g., nix: command not found),
this is not an exemption.
Do not label the work "UNVERIFIED" and proceed anyway.
Stop and tell the user the verification command is unavailable.
Detecting the Verification Command
Check the project root for these files and run the corresponding command:
| File | Command |
|---|---|
flake.nix |
nix flake check or nix build |
go.mod |
go build ./... and go test ./... |
Cargo.toml |
cargo build and cargo test |
build.zig |
zig build test |
package.json |
npm test |
Makefile |
make check or make test |
pyproject.toml |
pytest |
If multiple apply, run all that are relevant to the changed files.
If none apply, state explicitly: "No build/test command found for this project."
Do not treat absence of a build tool as permission to skip verification.
Red Flags
Stop immediately if you are about to:
- Say "should", "probably", "seems to" instead of running verification
- Express satisfaction before verification ("Great!", "Perfect!", "Done!")
- Commit or push without running the build/test command
- Claim "my tests pass" when the full suite has failures
- Say "looks correct" based on reading code instead of executing it
- Rationalize skipping verification ("simple change", "config only", "just docs")
Common Failures
| Claim | Requires | Not Sufficient |
|---|---|---|
| Tests pass | Full suite: 0 failures | "My new tests pass" |
| Build succeeds | Build command: exit 0 | Reading the diff |
| Bug fixed | Test reproducing symptom: passes | Code changed |
| Config works | Config evaluates without error | "Syntax looks valid" |
Verification Patterns
Build:
Good: Run `nix flake check` -> exit 0 -> "Build passes"
Bad: Read the diff -> "Looks correct" -> commitTests:
Good: Run full test suite -> 34/34 pass -> "All tests pass"
Bad: "My new tests pass" (ignoring pre-existing failures)Bottom Line
Run the command. Read the output. Then claim the result.
No exceptions.