| name | verification-before-completion |
| description | Use immediately before claiming work is complete, fixed, correct, or passing, and before publishing changes. Requires fresh, claim-specific evidence and accurate reporting of what was and was not verified. |
Verification Before Completion
Make completion claims only as broad as the evidence collected in the current work session.
Verification gate
Before reporting success or publishing changes:
- State the claim — Be precise about what you intend to say is complete or working.
- Choose evidence — Identify the smallest complete check that would prove that claim.
- Run it fresh — Execute the relevant command, reproduction, or inspection after the final change.
- Read the result — Check the exit code, failures, warnings, and whether the output actually covers the claim.
- Report accurately — State the evidence when it passes. When it fails or cannot run, report the actual status and limitation instead of implying success.
Evidence by claim
| Claim | Minimum useful evidence |
|---|
| Tests pass | Relevant test command completed with zero failures |
| Build succeeds | The actual build command exited successfully |
| Bug is fixed | The original reproduction no longer fails, plus relevant regression checks |
| Requirements are met | Each acceptance criterion checked against the result |
| Delegated work is complete | Inspect the real diff or artifact, then run relevant verification |
| Installation or deployment succeeded | Verify the installed or deployed state, not only the command submission |
Scope rules
- Match verification effort to risk and scope. Do not run an unrelated expensive suite merely for ceremony.
- A targeted check supports a targeted claim; it does not prove the whole repository is healthy.
- Previous runs, agent reports, code inspection, and confidence are context, not fresh verification.
- If a check is unavailable, say
not verified and explain why. Do not silently substitute a weaker check.
- Re-run affected checks after the last material edit; stale green output does not cover later changes.
- Distinguish warnings from failures and mention warnings that affect confidence or release safety.
Reporting pattern
Prefer concise evidence-backed status:
Verified: <command or reproduction> — <result>.Not verified: <missing check> because <reason>; confirmed only <narrower evidence>.Verification failed: <failure>; work is not complete.
Evidence first, then the completion claim.
