You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
45 lines
3.2 KiB
45 lines
3.2 KiB
2 months ago
|
---
|
||
|
|
name: "verification-before-completion"
|
||
|
|
description: "Gate any completion claim behind actual evidence - run the build, tests, or linter and read the output before saying something is done, fixed, passing, or ready. Use right before committing, opening a PR, marking a task complete, or telling the user it works. Covers the common failure modes and the red flags that mean you are about to claim success you have not verified. Triggers: is it done, are we finished, ship it, mark it complete."
|
||
|
|
---
|
||
|
|
|
||
|
|
Claiming work is complete without verification is dishonesty, not efficiency.
|
||
|
|
|
||
|
|
**Core principle:** evidence before claims, always.
|
||
|
|
|
||
|
|
**The Iron Law: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.** If you haven't run the verification command in this message/turn, you cannot claim it passes.
|
||
|
|
|
||
|
|
## The Gate Function
|
||
|
|
Before claiming any status or expressing satisfaction:
|
||
|
|
1. Identify what command proves this claim
|
||
|
|
2. Run the FULL command (fresh, complete — not a partial check or extrapolation)
|
||
|
|
3. Read the full output, check exit code, count failures
|
||
|
|
4. Does the output confirm the claim? If no, state actual status with evidence. If yes, state the claim WITH the evidence.
|
||
|
|
5. Only then make the claim.
|
||
|
|
|
||
|
|
Skipping any step is lying, not verifying.
|
||
|
|
|
||
|
|
## Common Failures and What's Actually Required
|
||
|
|
| Claim | Requires | NOT sufficient |
|
||
|
|
|---|---|---|
|
||
|
|
| Tests pass | fresh test command output, 0 failures | previous run, "should pass" |
|
||
|
|
| Linter clean | linter output, 0 errors | partial check |
|
||
|
|
| Build succeeds | build command, exit 0 | linter passing, logs "look good" |
|
||
|
|
| Bug fixed | test of the original symptom passes | code changed, assumed fixed |
|
||
|
|
| Regression test works | red-green cycle actually verified | test passes once |
|
||
|
|
| Agent/subagent completed | VCS diff shows the actual changes | agent's self-report of "success" |
|
||
|
|
| Requirements met | line-by-line checklist against spec | tests passing alone |
|
||
|
|
|
||
|
|
## Red Flags — STOP
|
||
|
|
Using "should"/"probably"/"seems to". Expressing satisfaction ("Great!", "Perfect!", "Done!") before verification. About to commit/push/PR without verification. Trusting a subagent's success report without checking its diff. Relying on partial verification. "Just this once." Being tired and wanting it over.
|
||
|
|
|
||
|
|
## Key Patterns
|
||
|
|
- Tests: run the command, see the actual pass count, THEN say "all tests pass." Not "should pass now."
|
||
|
|
- Regression tests: write → run (pass) → revert the fix → run (MUST fail) → restore fix → run (pass). Anything less isn't verified.
|
||
|
|
- Build: run the build, see exit 0. A passing linter is not proof the build compiles.
|
||
|
|
- Requirements: re-read the plan/spec, build a checklist, verify each item, report gaps or completion — not just "tests pass, phase complete."
|
||
|
|
- Subagent delegation: subagent reports success → check the actual VCS diff → verify the changes are real and correct → then report actual state.
|
||
|
|
|
||
|
|
## When To Apply
|
||
|
|
Always before: any success/completion claim, any expression of satisfaction, any positive statement about work state, committing, PR creation, task completion, moving to the next task, or trusting a delegated agent's report. Applies to exact phrases, paraphrases, and implications of success — not just the literal words.
|