git:20260717.70feb23 to git:20260720.fa58fb9
58 added, 118 removed. Audit A to A.
---
name: verification-before-completion
- description: Requires running verification commands and confirming output before making any success claims — evidence before assertions, always. Use when about to claim work is complete, fixed, or passing, before committing or creating PRs.
- license: MIT
+ description: >-
+ Evidence before success claims — identify the proof command, run it fresh,
+ read exit codes and output, then claim only what the evidence supports. Use
+ before marking work done, fixed, or passing; before commit or PR; whenever
+ tempted to assert status from build alone. Companion: test-driven-development
+ for constructing tests; systematic-debugging when verification fails.
metadata:
- source: https://github.com/obra/superpowers
- author: Jesse Vincent (obra)
+ source: original (devcake)
+ author: devcake
---
- # Verification Before Completion
-
- ## Overview
+ # Verification before completion
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 |
- | 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 |
+ **Iron law:** no completion claims without fresh verification evidence.
- ## Red Flags - STOP
+ If you have not run the proof command in this session and read its output,
+ you cannot claim it passes.
- - 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**
+ ## When this skill applies
- ## Rationalization Prevention
+ Use whenever you would say: done, fixed, green, shipped, ready for review,
+ or “should work.”
- | 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 |
+ Use before committing, opening/updating a PR, or writing a summary that
+ asserts quality.
- ## Key Patterns
+ This skill does **not** invent mission outcomes. Completion of a mission step
+ is defined by the playbook; this skill owns honesty of **evidence** for
+ technical claims inside that work.
- **Tests:**
- ```
- ✅ [Run test command] [See: 34/34 pass] "All tests pass"
- ❌ "Should pass now" / "Looks correct"
- ```
+ ## The gate
- **Regression tests (TDD Red-Green):**
- ```
- ✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
- ❌ "I've written a regression test" (without red-green verification)
- ```
+ Before any success claim:
- **Build:**
- ```
- ✅ [Run build] [See: exit 0] "Build passes"
- ❌ "Linter passed" (linter doesn't check compilation)
- ```
+ 1. **IDENTIFY** — what command(s) or checks prove this claim for *this* change?
+ 2. **RUN** — execute them fresh and complete (not a remembered earlier pass).
+ 3. **READ** — full relevant output, exit code, failure counts.
+ 4. **VERIFY** — does the output confirm the claim?
+ - If no: state actual status with evidence.
+ - If yes: state the claim **with** the evidence (command + result).
+ 5. **ONLY THEN** make the claim.
- **Requirements:**
- ```
- ✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
- ❌ "Tests pass, phase complete"
- ```
+ ## Choose proof that matches the change
- **Agent delegation:**
- ```
- ✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
- ❌ Trust agent report
- ```
+ Map the change type to the repository’s real verification path. Prefer what
+ owner docs, CI, and nearby code already use. Typical patterns:
- ## Why This Matters
+ | Change type | Minimum proof pattern |
+ |---|---|
+ | Library / app logic | Unit/integration tests for the touched seam |
+ | Container / image / compose | Image build **and** runtime/health where the user path is run/up |
+ | UI package | Build **and** load/health or the project’s UI test suite |
+ | Docs-only | Re-read for accuracy; no false runtime claims |
- 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."
+ **Stale image trap:** if tests run inside an image that COPY’d sources at
+ build time, re-running pytest on an old image grades the last bake, not the
+ working tree. Rebake, bind-mount, or run against the tree on the documented
+ runtime — never claim green from a stale artifact.
- ## When To Apply
+ “Build succeeded” alone is not proof when the user-facing path is run/up.
- **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
+ ## Report honestly
- **Rule applies to:**
- - Exact phrases
- - Paraphrases and synonyms
- - Implications of success
- - ANY communication suggesting completion/correctness
+ When summarizing:
- ## The Bottom Line
+ - Name what ran and what passed.
+ - Name what could **not** run and what remains unproven.
+ - Never imply full-system proof from a unit slice.
- **No shortcuts for verification.**
+ ## Anti-patterns
- Run the command. Read the output. THEN claim the result.
+ - “Should work” / “looks good” without a command
+ - Reusing an earlier test run after further edits
+ - Claiming CI green without seeing CI
+ - Fixing a test by deleting or weakening the assertion
+ - Partial suite green sold as full suite green
- This is non-negotiable.
+ ## Companion routing
- ---
- *Vendored from [obra/superpowers](https://github.com/obra/superpowers) (MIT). Modifications: body verbatim; frontmatter extended for the devcake skill store.*
+ - Failure under verification with unclear cause → `systematic-debugging`
+ - Need a new failing test for the fix → `test-driven-development`
+ - Packaging the change for review → `pr-hygiene` (if available)