---

name: verification-before-completion description: "Verify work actually meets its brief BEFORE declaring it done — a structured self-review pass that catches the gaps, unmet requirements, and untested claims that 'looks finished' hides. Use when about to hand over any deliverable (document, code, analysis, plan), when past work kept coming back with 'you missed…', or as the standing final step of any multi-step task. Produces the verified deliverable plus a short verification record: what was checked, what was found and fixed, what remains open."

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

Example Trigger Phrases

• "Check this is really done."
• "Verify this meets the brief before I send it."
• "Review my deliverable against the requirements."
• "What's missing before we call this finished?"