---
name: verification-before-completion
description: Use before reporting any task as done, especially when the work was done by a delegate/subagent. Never relay a self-report as fact.
license: MIT
source: adapted from obra/superpowers (MIT license), condensed for delegate-brief reuse
---

# Verification Before Completion

**A delegate's "done" is a claim, not a fact.** This applies whether the
delegate is another AI agent, a subagent, or your own past self in an
earlier step. Re-derive the result yourself before reporting completion
to whoever is waiting on it.

## The rule

Never report "done" based solely on:
- A delegate saying it's done.
- A test that wasn't actually re-run by you.
- Code that "should work" based on reading it, when running it was possible.

Instead, for each claim, do the cheapest check that would actually catch
a wrong claim:

| Claim | Real check |
|---|---|
| "The file was created" | `ls`/`cat` it yourself |
| "The syntax is valid" | Actually run the linter yourself, don't trust a self-report of having run it |
| "The tests pass" | Run them yourself, read the actual output |
| "The API returns X" | Make the actual call yourself |
| "The deploy succeeded" | Check the live system, not the deploy log's exit code alone |
| "The old code is gone" | grep for it yourself |

## Why this matters (not just process theater)

Across a real multi-delegate session, every single delegate's first
self-report claimed success. Independent re-verification (re-running the
linter, re-grepping, and — critically — testing the actual live
end-to-end pipeline rather than just checking that files existed) is
what actually confirmed correctness. In an earlier phase of the same
session, a wrapper-agent pattern (spawn an agent whose only job is to
invoke one CLI tool and report back) repeatedly ended its own turn the
instant it *started* a background process, before that process had
produced any real result — producing a loop of confident-sounding "still
running" reports that carried zero information. The fix was to stop
trusting the wrapper's self-reported status and directly monitor the
actual underlying process.

## Escalating verification for higher-stakes changes

- Low-stakes (a text file, a doc change): read it back.
- Medium-stakes (application code): lint + a targeted functional test.
- High-stakes (something that serves real traffic, handles money, or
  changes shared/production state): the *actual* end-to-end path a real
  user would hit — not a unit test in isolation, the real live pipeline.
  If you cannot exercise the real path yourself (e.g. no browser
  available for a checkout flow), say so explicitly rather than reporting
  success on a partial check.

## What NOT to do

Don't pad out a report with hedging language as a substitute for actually
checking ("this should work", "this is likely correct"). Either verify
it, or clearly state it's unverified and why — don't blur the line
between the two.