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