verification-before-completion

Verification Before Completion - Verify Before Finishing

Skill Overview

Before declaring work complete, repairs successful, or tests passed, you must run verification commands and confirm the output results—evidence always comes before assertions.

Applicable Scenarios

1. Before Submitting Code and Creating a PR

Before running git commit or creating a Pull Request, run the full test suite, build commands, and code-checking tools to ensure all verifications pass and that there is real, tangible output evidence. This prevents unfinished code from being pushed to a shared repository.

2. After Feature Development and Bug Fixing

After completing feature development or fixing a bug, verify the fix by running the tests with real execution. For regression tests, you must perform the full red-green refactoring loop: write tests → run (pass) → roll back the fix → verify (must fail) → restore the fix → run again (pass).

3. After Delegating Tasks to an AI Agent

When delegating a task to an AI agent or sub-agent, you cannot treat the agent’s “successful” report as proof the task is complete. You must check the VCS diff, run independent verification commands, and confirm that the actual changes match expectations.

Core Functions

Evidence-Driven Verification

It is mandatory that, before declaring any success state, you must run verification commands and obtain actual output. The core rule is: without fresh verification evidence, you cannot claim completion. This applies to all scenarios—tests passing, build success, bug fixes, requirement fulfillment, and more.

Defensive Verification Procedure

Use a five-step verification process to prevent false completion:
(1) Identify the command(s) that claim proof
(2) Execute the command(s) completely
(3) Read the full output and exit code
(4) Confirm whether the output supports the claim
(5) Only then may you make the declaration.
Skipping any step counts as dishonesty.

Red-Green Refactoring Loop

For regression testing and TDD, you must perform the complete validation cycle: write tests → run (pass) → roll back the fix → run (must fail) → restore the fix → run (pass). Running only once with a pass is not enough to prove the tests are valid.

Common Questions

Why is “It should pass” not valid verification?

Because “should” expresses a guess rather than evidence. Verification is about obtaining actual run results. Even if you have 100% confidence in the code, you must run the commands to get real output. Many historical failures come from overconfidence and skipping verification.

The agent reported success—why do we still need independent verification?

The agent’s success report may be based on incomplete checks, incorrect assumptions, or only partial testing. As the delegator, you need to independently run verification commands to confirm the actual state. This is similar to code review—the author’s claims cannot replace the reviewer’s verification.

Why verify the failure step in regression tests?

If your tests still pass after rolling back the fix, it means the tests are not truly validating the fix logic. The issue may be with the test itself or it may be a false positive. The red-green refactoring loop ensures that tests genuinely verify what they are supposed to verify. This is basic TDD discipline.