Mohit Aggarwal 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