verification-before-completion_skill

Overview

This skill enforces running concrete verification commands before claiming work is complete, fixed, or passing. It prevents hedged or unverified statements by requiring fresh evidence (commands, outputs, exit codes) before asserting success. Follow it to reduce rework, avoid false positives, and preserve trust across teams.

How this skill works

Before any claim of completion, identify the single command or sequence that proves the claim, run it fresh, and inspect full output and exit codes. If the output confirms the claim, attach that evidence when stating completion; if not, report the actual status with the verification output. Skipping any step invalidates the claim.

When to use it

• Before stating tests pass, a build succeeds, or a linter is clean
• Before marking tasks complete, creating PRs, or merging changes
• Before delegating work or moving to the next task
• When an agent, tool, or teammate reports success
• Before using any hedging or satisfaction language (e.g., "Done", "Should work")

Best practices

• Always run the full verification command (no spot-checks) and preserve output
• Check exit codes and failure counts, not just human-readable summaries
• Include the verification command and key output snippets when claiming success
• Reproduce red→green cycles for regression tests to prove fixes
• Avoid trusting prior runs or tool success messages without independent verification

Example use cases

• Run yarn test and attach the zero-failure output before claiming tests pass
• Execute the build command and confirm exit 0 before saying the build succeeds
• Run the linter to completion and show 0 errors before claiming linter clean
• After an agent reports success, run git diff and verify expected changes before accepting
• For a bug fix, include a test that failed then passed and show the red→green cycle