Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add KhaledSaeed18/dotclaude --skill verify-completiongit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/khaledsaeed18/dotclaude/verify-completion)<a href="https://agentmods.dev/skills/khaledsaeed18/dotclaude/verify-completion"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/verify-completion/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/khaledsaeed18/dotclaude/verify-completion"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/verify-completion.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00069 | $0.00772 |
| Opus 5.5 | $0.00028 | $0.00309 |
| Sonnet 5.5 | $0.00014 | $0.00154 |
| Haiku 4.5 | $0.00007 | $0.00077 |
Grade A, and why
verify-completion scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 28d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Don't claim work is done, fixed, or passing unless you've just run the thing that proves it and read the output. Saying it's complete when you haven't checked isn't optimism; it's reporting something you don't know to be true, and it breaks trust the moment it turns out wrong.
The one rule
No completion claim without fresh verification. If you haven't run the verifying command in this turn, you can't say it passes. "Should pass now", "I'm confident", "the logs looked fine" are not evidence; they're the feelings that precede unverified claims.
The gate
Before stating any status, or even expressing satisfaction ("great", "perfect", "done"):
- Identify the command that would prove the claim.
- Run it: the full command, fresh, start to finish. Not a partial check, not a remembered result from earlier.
- Read the whole output: exit code, failure count, warnings.
- Decide. Does the output actually confirm the claim? If not, state the real status with the evidence. If so, state the claim with the evidence.
Skipping any of these steps turns a verification into a guess.
What each claim actually requires
| Claim | What proves it | What does not |
|---|---|---|
| Tests pass | A fresh test run showing 0 failures | A previous run; "should pass" |
| Linter clean | Linter output, 0 errors | A partial check; extrapolating |
| Build succeeds | Build command, exit 0 | Linter passing; logs "looking good" |
| Bug fixed | The original symptom retested and gone | The code changed, so it's "probably fixed" |
| Regression test works | Watched it fail before the fix, pass after | It passes once now |
| Requirements met | A line-by-line pass over the requirements | Tests passing |
| Subagent finished | The actual diff / output inspected | The subagent reporting "success" |
A linter passing doesn't mean it compiles. A subagent saying "done" doesn't mean it did the work, check the diff. A regression test that's only ever passed hasn't been shown to catch anything; verify it fails without the fix, then passes with it.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 28d ago Changed · +4 lines a6ffb838e7b5
- 1mo ago First seen · 52 lines · 69 tokens per session scan A 8d13ddee80c3
verify-completion is a skill published in the GitHub repository KhaledSaeed18/dotclaude (5 stars, last pushed 6d ago), licensed MIT. It adds 69 tokens to every session and 772 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
qa-testing
Run QA testing on a page, feature, or full site at one of three depth tiers (smoke, standard, full). Use this skill whenever the user asks to QA a page or site, run a smoke test after a deploy, verify a page before launch, or run a regression sweep. Triggers on QA, QA sweep, smoke test, regression test, post-deploy…
visual-qa
Runs rigorous visual QA across web, terminal, and paginated surfaces: an Apple HIG-based checklist, paired light/dark captures at phone and desktop widths, screenshot evidence, and a per-item PASS/FAIL verdict. Use for any UI build or change, or when asked whether a page, component, or TUI looks right or follows the…
remove-ai-slops
Removes AI-generated code smells from branch changes or an explicit file list behind regression tests. Use when the user asks to clean up, deslop, or remove AI-slop patterns from recent changes.
senpi-qa
QA the omo Senpi adapter (packages/omo-senpi, packages/senpi-task) against the REAL senpi binary in strict isolation, and write every artifact to the one canonical evidence path .omo/evidence/omo-senpi-adapter/ /. The live drivers under packages/omo-senpi/scripts/qa/ create their own isolated SENPICODINGAGENTDIR and…
test-coverage-improver
Analyze test coverage gaps and generate tests to improve coverage. Use when improving test coverage, finding untested code, or writing missing tests.
browser-test-loop
Use to actually verify a web change in a real browser instead of assuming it works — click through a flow, catch console errors, check a form submits, confirm a fix on the page. Trigger when a UI change needs proof, a bug only reproduces in the browser, or the user asks to test, check, or screenshot the running app.