Agent Skills
› mohitagw15856/pm-claude-skills
› verification-before-completion
verification-before-completion
GitHub在交付前对工作进行结构化自查，通过重读需求、验证声明、运行测试及对抗性审查，确保成果符合原始要求。产出修复后的交付物及包含发现与残留问题的验证记录，减少返工。
触发场景
准备提交文档、代码或分析报告等最终交付物时
过往工作常因遗漏细节被退回时
多步骤任务的最后收尾阶段
安装
npx skills add mohitagw15856/pm-claude-skills --skill verification-before-completion -g -y
SKILL.md
Frontmatter
{
"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 before handing 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
版本历史
- a38bc30 当前 2026-07-05 11:46
