Why does it flag words like 'should' or 'probably'?

These words indicate assumptions rather than evidence. The skill treats any wording implying success without verification as a violation of the development protocol.

Does this skill work with build systems and linters?

Absolutely. It distinguishes between partial checks (like a linter) and full verification (like a compiler exit code 0 or 100% test pass rate).

Can I use this for Test-Driven Development (TDD)?

Yes, it specifically enforces patterns for regression testing, requiring a verified red-green cycle where the test fails before the fix and passes after.

What is the primary purpose of the Verified Completion Guard?

It ensures that Claude never claims a task is finished or a bug is fixed without first executing the relevant verification commands and confirming the output.

How does this skill handle 'hallucinated' success?

It forces a 'Gate Function' where the AI must identify the proof-of-work command, run it, and read the full output before it is allowed to express satisfaction or completion.

Verified Completion Guard

Name: Verified Completion Guard
Author: julianromli

byjulianromli

•

Security & Testing

Enforces a strict evidence-based workflow that requires running verification commands before any coding task is claimed as complete.

About

The Verified Completion Guard skill implements a rigorous 'Iron Law' for AI-driven development, ensuring that no completion claims, PRs, or commits are made without fresh, verifiable evidence. By mandating a specific gate function—Identify, Run, Read, and Verify—it eliminates common AI failure patterns such as assuming a fix works or relying on partial linter passes. This skill is essential for teams prioritizing high-integrity code and seeking to eliminate 'hallucinated success' where agents report completion before truly validating the output against requirements.

Key Features

Detection and prevention of non-committal language like 'should' or 'probably'
Red-Green TDD cycle enforcement to prove bug fixes
Independent auditing of delegated agent reports and VCS diffs
Mandatory 'Iron Law' verification gate for all status claims
Standardized verification patterns for tests, builds, and regressions
12 GitHub stars

Use Cases

Ensuring bug fixes are validated against the original failing symptom before closing tickets
Maintaining a high-trust development environment by requiring command output for every success claim
Preventing broken code or failing builds from being merged into production branches

About

Key Features

Detection and prevention of non-committal language like 'should' or 'probably'
Red-Green TDD cycle enforcement to prove bug fixes
Independent auditing of delegated agent reports and VCS diffs
Mandatory 'Iron Law' verification gate for all status claims
Standardized verification patterns for tests, builds, and regressions
12 GitHub stars

Use Cases

Ensuring bug fixes are validated against the original failing symptom before closing tickets
Maintaining a high-trust development environment by requiring command output for every success claim
Preventing broken code or failing builds from being merged into production branches