What is the 'Iron Law' in this skill?

The Iron Law states that no completion claims can be made without fresh verification evidence. If a command hasn't been run in the current context, the task cannot be claimed as passed.

What happens if a linter passes but the build fails?

The skill treats these as distinct requirements. A linter passing is not sufficient evidence for a build succeeding; each specific claim requires its own unique verification command.

How does this prevent 'hallucinated' success?

It forces the AI to identify a specific command that proves a claim, execute it, and report the actual output and exit codes before using words like 'Done' or 'Fixed'.

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

Yes, it includes specific patterns for Red-Green verification, requiring a test to fail before the fix is applied and pass after, ensuring the test is actually valid.

Verification Before Completion

Name: Verification Before Completion
Author: jagreehal

byjagreehal

Security & Testing

Ensures all tasks are validated with fresh evidence and command execution before any success claims are made.

About

The Verification Before Completion skill enforces a strict 'evidence-first' policy for Claude Code, preventing premature or unverified claims of success. By mandating the execution of fresh verification commands—such as test suites, build scripts, and linters—before any work is declared complete, it eliminates assumptions and 'should-work' statements. This skill provides a rigorous gate function that requires identifying proof, running commands, and analyzing exit codes, ensuring that every code change is backed by concrete evidence and significantly reducing the risk of regressions or false positives.

Key Features

Implements a structured Gate Function (Identify, Run, Read, Verify) for all tasks
Supports TDD Red-Green patterns to ensure regression tests are valid
Defines specific validation requirements for builds, tests, linting, and type-checks
Detects and flags non-committal language like 'should,' 'probably,' or 'seems to'
Enforces the 'Iron Law' of mandatory fresh evidence before success assertions
0 GitHub stars

Use Cases

Confirming bug fixes by verifying fresh regression test results instead of assuming code changes worked
Validating full build and type-safety integrity before committing or pushing changes to a repository
Systematically verifying complex requirement checklists to ensure 100% compliance with project specs

About

Key Features

Implements a structured Gate Function (Identify, Run, Read, Verify) for all tasks
Supports TDD Red-Green patterns to ensure regression tests are valid
Defines specific validation requirements for builds, tests, linting, and type-checks
Detects and flags non-committal language like 'should,' 'probably,' or 'seems to'
Enforces the 'Iron Law' of mandatory fresh evidence before success assertions
0 GitHub stars

Use Cases

Confirming bug fixes by verifying fresh regression test results instead of assuming code changes worked
Validating full build and type-safety integrity before committing or pushing changes to a repository
Systematically verifying complex requirement checklists to ensure 100% compliance with project specs