verify-completion

Validates completion claims by requiring fresh verification command output before reporting success.

Updated May 3, 2026
One-click install
npx skills add https://github.com/Claudfather/clauDNA --skill verify-completion-claudfather
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify-completion
Source: https://github.com/Claudfather/clauDNA/tree/main/skills/verify-completion
Command: npx skills add https://github.com/Claudfather/clauDNA --skill verify-completion-claudfather

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI agents and developers often claim work is complete, fixed, or passing based on assumptions, stale results, or partial checks, which ships broken code. This Skill enforces an evidence-first gate that blocks any success claim until a verification command has been run fresh and its output confirms the claim. ## Core Features & Use Cases - Verification Gate: A five-step protocol (identify, run, read, verify, claim) that must complete before any completion, fix, or passing claim is made. - Claim-to-Evidence Matching: Distinguishes behavioral claims (requiring running the app and observing its surface) from mechanical claims (requiring fresh test, build, or linter output), so green tests are not misused as proof a feature works. - Full-Scope Diff Checks: Uses git diff ranges against upstream or PR diffs to verify the complete change rather than a stale or partial view. - Use Case: Before committing a bug fix, run the reproduction steps and the test suite, read the full output, and only then report the fix as verified with the evidence attached. ## Quick Start Ask the agent to verify that the current changes actually work before claiming the task is done.

Frequently Asked Questions about verify-completion

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify code changes are complete before committing?

Identify the command that proves your claim, run it fresh, read the full output and exit code, then confirm the output supports the claim. Only state success after this sequence, and check the full branch diff with git diff @{u}.. --stat to cover the complete change.

Why are passing tests not enough to claim a bug is fixed?

Passing tests prove the test suite runs, not that the original symptom is resolved. A behavioral claim requires running the app to where the change executes and observing the actual behavior, such as CLI output, an HTTP response, or rendered UI.

What counts as valid verification evidence for a build or linter?

Mechanical claims like build succeeds or linter clean require that exact command's fresh output showing exit code 0 or zero errors. A linter passing does not prove the build compiles, and a previous run does not prove the current state.

What should I report when verification cannot be run?

Report the work as blocked, not done, and name exactly where verification stopped, such as a broken build or missing dependency. Stating you could not verify because of a specific cause is honest; an unbacked success claim is not.

Can I trust a subagent's success report without checking it?

No. A subagent's report of success is itself a claim that requires independent verification. Check the VCS diff to confirm the expected changes exist and run the relevant verification commands yourself before relaying the result.