verification-before-completion
starsforks
How to install verification-before-completion?
archive228/loopkit/verification-before-completion
$npx -y skills add Archive228/loopkit --skill verification-before-completionUse before claiming work is complete, fixed, or passing — before committing, opening a PR, or handing off. Requires running the verification command in THIS turn and reading its output before any success claim.
SKILL.md
| 1 | # Verification Before Completion |
| 2 | |
| 3 | Claiming work done without fresh verification is dishonesty, not efficiency. `adversarial-verify` is the *what*; this skill is the *when* — the gate you pass through right before any completion claim. |
| 4 | |
| 5 | ## The Iron Law |
| 6 | |
| 7 | ``` |
| 8 | NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE |
| 9 | ``` |
| 10 | |
| 11 | If you have not run the verification command in this message, you cannot claim it passes. Not "should", not "probably", not "based on the diff". |
| 12 | |
| 13 | ## The gate function |
| 14 | |
| 15 | Before writing "done" / "fixed" / "green" / "ready to merge" — even in your own head: |
| 16 | |
| 17 | 1. **Identify** — what exact command proves this claim? |
| 18 | 2. **Run** — execute it fresh, complete, in this turn. |
| 19 | 3. **Read** — full output, check exit code, count failures. |
| 20 | 4. **Verify** — does the output actually confirm the claim? |
| 21 | 5. **Only then** — make the claim, with the evidence attached. |
| 22 | |
| 23 | Skip any step = you are lying to the user, not verifying. |
| 24 | |
| 25 | ## Common false claims → what they actually need |
| 26 | |
| 27 | | Claim | Requires | Not sufficient | |
| 28 | |---|---|---| |
| 29 | | Tests pass | Fresh test run, exit 0, 0 failures | "should pass", previous run, "logic looks right" | |
| 30 | | Linter clean | Linter output, 0 errors | Partial check, extrapolating from unrelated files | |
| 31 | | Build succeeds | Build command, exit 0 | Linter passing, editor squiggles gone | |
| 32 | | Bug fixed | Reproduce original symptom, watch it not happen | Code changed, "assumed" fixed | |
| 33 | | Regression test works | Red → green cycle verified (revert fix, watch test fail, restore, watch pass) | Test passes once | |
| 34 | | Agent/subagent completed | Read the VCS diff, verify claimed changes exist | Agent's own "success" report | |
| 35 | | Spec satisfied | Line-by-line checklist against the plan | "Tests pass, phase complete" | |
| 36 | |
| 37 | ## Red flags — you are about to claim without verifying |
| 38 | |
| 39 | - Words like "should", "probably", "seems to", "looks good" |
| 40 | - Satisfaction language ("Great!", "Perfect!", "Done!") before running the command |
| 41 | - About to commit / push / open PR without a verification block in this turn |
| 42 | - Trusting a subagent's own success report |
| 43 | - "Just this once" thinking, or "I'm tired, close enough" |
| 44 | - Partial verification (linter passed, so build must) |
| 45 | |
| 46 | ## Rationalization prevention |
| 47 | |
| 48 | | Excuse | Reality | |
| 49 | |---|---| |
| 50 | | "Should work now" | RUN it. | |
| 51 | | "I'm confident" | Confidence ≠ evidence. | |
| 52 | | "Linter passed" | Linter ≠ compiler ≠ tests. | |
| 53 | | "The agent said success" | Read the diff yourself. | |
| 54 | | "Partial check is enough" | Partial proves nothing about the whole. | |
| 55 | | "Different words, so rule doesn't apply" | Spirit over letter. | |
| 56 | |
| 57 | ## Patterns |
| 58 | |
| 59 | **Tests** |
| 60 | - Run the test command. See `34/34 pass`. Then say "all tests pass". |
| 61 | - Never: "should pass now". |
| 62 | |
| 63 | **Regression tests (real red-green)** |
| 64 | - Write test → run (pass) → revert fix → run (MUST FAIL) → restore fix → run (pass). |
| 65 | - Never: "I've added a regression test" without the red-green cycle. |
| 66 | |
| 67 | **Build** |
| 68 | - Run the build. See exit 0. Then say "build passes". |
| 69 | - Never: "linter passed, build should too". |
| 70 | |
| 71 | **Agent delegation** |
| 72 | - Subagent reports success → check the VCS diff → verify the claimed change is actually there → report actual state. |
| 73 | - Never: paste the agent's report and treat it as truth. |
| 74 | |
| 75 | ## When this fires |
| 76 | |
| 77 | Always, before: |
| 78 | - Any variation of success / completion / fixed / passing / green |
| 79 | - Committing, opening a PR, marking a task done, handing off |
| 80 | - Moving to the next task |
| 81 | - Any positive statement about the work's state |
| 82 | |
| 83 | ## Pair with |
| 84 | |
| 85 | - `adversarial-verify` — the 11 shortcuts agents take to fake "done"; run through the list, then run through this gate. |
| 86 | - `clean-commits` — clean commits require verified content. |
| 87 | - The `verifier` subagent — dispatch it; then verify its report against the diff (per the "Agent delegation" pattern above). |
| 88 | |
| 89 | ## The bottom line |
| 90 | |
| 91 | Run the command. Read the output. THEN claim the result. Non-negotiable. |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
