# Verification Before Completion Skill

"Done" is a claim, and most agents (and humans) declare it by *feeling* — the output looks complete, reads well, compiles. This skill replaces the feeling with a check: re-derive what was actually asked, audit the work against it, try to break it, and only then hand it over. The gap between looks-done and is-done is where rework lives.

## What This Skill Produces

- The deliverable, **after** fixes the verification pass surfaced
- A **verification record** (3-8 lines): checked against what, found and fixed what, still open what
- Honest **residuals**: anything not verified, stated rather than implied

## The Verification Pass

1. **Re-read the ORIGINAL ask — not your memory of it.** Requirements decay in working memory over a long task; the third instruction in the user's message is the classic casualty. List every explicit requirement and every implicit one (format, tone, length, audience) as a checklist. *Then* audit the work against the list, item by item.
2. **Check the claims, not just the presence.** A section existing isn't the section being right. For each substantive claim/number/behaviour in the deliverable: is it grounded (traceable to input, source, or test) or asserted? Every ungrounded assertion either gets grounded, gets labelled as an assumption, or gets cut.
3. **Run what can be run.** Code: run it — the suite, the build, the actual command; "should work" is not a verification. Documents: run the artifact's own quality checks (if it was produced by a skill, that skill's Quality Checks section is the checklist). Analyses: re-run the one query/calculation the conclusion hangs on.
4. **Attack it like the recipient will.** One adversarial read: What would the sceptical reader poke first? What's the weakest section? What question does this raise that it doesn't answer? Fix what the attack finds, or pre-empt it in the deliverable.
5. **Check the seams.** Multi-part work fails at joints: does the summary match the body? Do the numbers agree between sections? Did a late edit orphan an earlier reference? Consistency errors are the most visible-to-reader, least visible-to-author class.
6. **Write the record, including the shame.** What was checked, what was found (finding things is the *success* of this pass, not a confession), what was fixed, what remains open. A verification record with zero findings on non-trivial work usually means the pass was performative — say what you actually did.

## Output Format

*(appended to, or accompanying, the deliverable)*

**Verified:** against [the original ask, N requirements] · [ran: tests/checks/queries] · [1 adversarial read]
**Found & fixed:** [the 1-4 real findings]
**Open / not verified:** [residuals, stated — "performance under load not tested"]

## Quality Checks

- [ ] The original request was re-read verbatim, and every requirement (incl. implicit format/tone/length) was audited
- [ ] Everything runnable was actually run — no "should work" in the record
- [ ] At least one adversarial read happened, from the recipient's perspective
- [ ] Cross-section consistency was checked (summary↔body, numbers↔numbers)
- [ ] The record states residuals honestly rather than implying total coverage

## Anti-Patterns

- [ ] Do not verify against your memory of the ask — memory is where the third requirement went to die
- [ ] Do not treat a clean-looking output as evidence — polish and correctness are uncorrelated at exactly the worst moments
- [ ] Do not skip the pass under time pressure — the pass is minutes; the rework it prevents is hours
- [ ] Do not produce a zero-findings record on complex work — that's theatre; look harder or say what you couldn't check
- [ ] Do not hide residuals to seem finished — an honest "untested under X" builds more trust than the failure it predicts