# Process Review Verification Before Completion > Use when about to claim work is complete, fixed, or passing, before committing, opening a PR, or moving to the next task, or when about to express satisfaction with a result ("done", "looks correct", "should work now") or trust an agent's success report - Skill: `bitranox/process-review-verification-before-completion` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add bitranox/process-review-verification-before-completion` - Raw SKILL.md: https://api.skillmd.com/api/skills/bitranox/process-review-verification-before-completion/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: bitranox (https://skillmd.com/u/bitranox) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/bitranox/process-review-verification-before-completion --- # Verification Before Completion > Adapted from the superpowers plugin (MIT). ## Overview Claiming work is complete without verification is dishonesty, not efficiency. **Core principle:** Evidence before claims, always. **Violating the letter of this rule is violating the spirit of this rule.** ## The Iron Law ``` NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE ``` If you haven't run the verification command in this message, you cannot claim it passes. ## The Gate Function ``` BEFORE claiming any status or expressing satisfaction: 1. IDENTIFY: What command proves this claim? 2. RUN: Execute the FULL command (fresh, complete) 3. READ: Full output, check exit code, count failures 4. VERIFY: Does output confirm the claim? - If NO: State actual status with evidence - If YES: State claim WITH evidence 5. ONLY THEN: Make the claim Skip any step = lying, not verifying ``` ## Common Failures | Claim | Requires | Not Sufficient | |------------------------|---------------------------------|--------------------------------| | Tests pass | Test command output: 0 failures | Previous run, "should pass" | | Linter clean | Linter output: 0 errors | Partial check, extrapolation | | Build succeeds | Build command: exit 0 | Linter passing, logs look good | | Bug fixed | Test original symptom: passes | Code changed, assumed fixed | | Failure class resolved | Full gate re-run: 0 remaining | One fix, assumed the rest | | Regression test works | Red-green cycle verified | Test passes once | | Agent completed | VCS diff shows changes | Agent reports "success" | | Requirements met | Line-by-line checklist | Tests passing | | Write landed | Read back from the SAME layer | A read served by another layer | ### Read it back from the layer the write landed in Reading a value back only proves anything when the read is served by the SAME layer the write targeted. A write to a STORED/persisted layer is invisible to a RUNTIME read, and the runtime read does not fail - it returns well-formed, plausible, OLD data. So a successful write reads as a failed one, and after a reload the reverse: a write that never persisted reads as applied. The pairs that produce this are everywhere once you look for them: | Wrote to | A read that will LIE about it | |------------------------------|-------------------------------| | the git index (`git add`) | the working tree | | a config file on disk | the already-running process | | a systemd unit file | the loaded unit (`show`) | | a device's stored settings | its current running settings | The instrument reporting "unchanged" is not evidence the write failed, and "changed" is not evidence it persisted. Name BOTH layers explicitly and say which one you just read. If the stored layer has no read path of its own, force the transition (reload, restart, reboot) and verify AFTER it - that is the only read that covers both. ## Red Flags - STOP - Using "should", "probably", "seems to" - Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.) - About to commit/push/PR without verification - Trusting agent success reports - Relying on partial verification - Thinking "just this once" - Tired and wanting work over - **ANY wording implying success without having run verification** ## Rationalization Prevention | Excuse | Reality | |-----------------------------------------|------------------------| | "Should work now" | RUN the verification | | "I'm confident" | Confidence ≠ evidence | | "Just this once" | No exceptions | | "Linter passed" | Linter ≠ compiler | | "Agent said success" | Verify independently | | "I'm tired" | Exhaustion ≠ excuse | | "Partial check is enough" | Partial proves nothing | | "Different words so rule doesn't apply" | Spirit over letter | ## Key Patterns **For a risky/large completion claim, get an INDEPENDENT verifier.** You cannot fully check your own work (you share the doer's optimism). Dispatch an **`opus`** adversarial verifier subagent with fresh context (re-run the commands ITSELF, check requirements line-by-line, try to DISPROVE "done") - correctness verification is exactly the deep-reasoning role that warrants opus. The verifier RUNS the commands rather than reading yours: a verifier handed your output inherits the same optimism this section says you cannot check in yourself, and a misreported result is exactly what survives that. (Tiers: "Concrete tiers" in `bitranox:process-agents-subagent-driven-development`.) **Tests:** ``` OK [Run test command] [See: 34/34 pass] "All tests pass" NO "Should pass now" / "Looks correct" ``` **Regression tests (TDD Red-Green):** ``` OK Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass) NO "I've written a regression test" (without red-green verification) ``` On the revert, the test must fail **with the bug's own symptom** - not an import error, a fixture blowing up, or a different assertion. A test that fails for an unrelated reason passes red-green while proving nothing about the bug. **Build:** ``` OK [Run build] [See: exit 0] "Build passes" NO "Linter passed" (linter doesn't check compilation) ``` **Fail-fast gates (unmasking):** ``` OK Fix -> rerun the FULL gate -> gate's own verdict is green -> THEN claim the class resolved NO One fix -> reason from your model of the cause -> claim all N items fixed ``` A gate that aborts at the first error (rustc, most compilers, staged pipelines, a fail-fast test runner) hides every failure after it. Fixing the first only lets the gate run far enough to expose the second - it does not prove the second is fixed too. Re-run the gate itself and require its own green line before reporting the failure class resolved. **Requirements:** ``` OK Re-read plan → Create checklist → Verify each → Report gaps or completion NO "Tests pass, phase complete" ``` **Agent delegation:** ``` OK Agent reports success → Check VCS diff → Verify changes → Report actual state NO Trust agent report ``` ## Why This Matters From 24 failure memories: - your human partner said "I don't believe you" - trust broken - Undefined functions shipped - would crash - Missing requirements shipped - incomplete features - Time wasted on false completion → redirect → rework - Violates: "Honesty is a core value. If you lie, you'll be replaced." ## When To Apply **ALWAYS before:** - ANY variation of success/completion claims - ANY expression of satisfaction - ANY positive statement about work state - Committing, PR creation, task completion - Moving to next task - Delegating to agents **Rule applies to:** - Exact phrases - Paraphrases and synonyms - Implications of success - ANY communication suggesting completion/correctness ## The Bottom Line **No shortcuts for verification.** Run the command. Read the output. THEN claim the result. This is non-negotiable. A verified claim is still only a true one. Whether the choices behind it were the RIGHT choices is a different question, and this skill does not ask it - `bitranox:process-review-uncertain-decisions` does.