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.
Start a fresh conversation. Replace the highlighted placeholders.
Use verification-before-completion to review [deliverable] against [original brief], fix supported findings, and provide the verified deliverable plus a concise record of checks, fixes, and remaining unverified residuals.
Required inputs
[deliverable]
[original brief]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: verification-before-completiondescription: "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
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.
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.
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.
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.
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.
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