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 komluk/scaffolding --skill verification-before-completiongit clone --depth 1 https://github.com/komluk/scaffoldingWrote 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/komluk/scaffolding/verification-before-completion)<a href="https://agentmods.dev/skills/komluk/scaffolding/verification-before-completion"><img src="https://agentmods.dev/badge/skills/komluk/scaffolding/verification-before-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/komluk/scaffolding/verification-before-completion"><img src="https://agentmods.dev/badge/skills/komluk/scaffolding/verification-before-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.00073 | $0.00955 |
| Opus 5.5 | $0.00029 | $0.00382 |
| Sonnet 5.5 | $0.00015 | $0.00191 |
| Haiku 4.5 | $0.00007 | $0.00096 |
Grade A, and why
verification-before-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 1mo 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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verification Before Completion Skill
Purpose
A claim of "done" is only as good as the check that produced it. This skill encodes the rule that every completion claim, and every fact a claim depends on, must be backed by something actually executed and observed — not assumed, remembered, or guessed — before it is reported.
When to Apply
Apply this skill when:
- About to report a task, fix, or feature as complete
- Confirming that a build, test, deploy, or query actually succeeded
- Stating a fact about a file, branch, or config that the response depends on
- Delegating a task to another agent or tool
Do NOT apply this skill for:
- Scoring a ResearchPack or Implementation Plan against quality gates before work starts — use
quality-validation - Deciding what and how much to test — use
testing-strategy
Verification Rules
| Rule | Requirement |
|---|---|
| Prove before claiming | Run the actual command that demonstrates the outcome (test suite, build, the real query) and read its output. Exit code 0 alone is not proof of correctness — check the output content. |
| Verify against the authoritative source | Confirm facts (file existence, path, branch content, config value) against the actual target (e.g. main, prod). A stale checkout, cached artifact, or side branch is not evidence about the target. |
| One failure = investigate | After a failed attempt, diagnose the actual cause before trying again. Do not retry the same action with a blind variation. |
| Two guesses = stop | If a second consecutive guess is about to be made without new evidence, stop. Search the codebase for an existing pattern (grep) instead of guessing again. |
| Check capability before delegating | Confirm the executor (agent or tool) actually has the access/tools the task requires before handing it off. |
| Absence of error is not success | Not seeing an error is not the same as confirming success. Only a positive, observed result counts as verification. |
| State the verification | Report what was verified and how (command run, output observed) so the claim is auditable by someone else. |
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.
- 1mo ago First seen · 74 lines · 73 tokens per session scan A 141808edc107
verification-before-completion is a skill published in the GitHub repository komluk/scaffolding (15 stars, last pushed 4d ago), licensed MIT. It adds 73 tokens to every session and 955 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-09-21.
Other skills, from other repositories
completion-verification
Verifies that work is actually complete before it is claimed to be — running the checks, reading the output, and confirming the original request was satisfied rather than approximated. Use this before saying something is done, fixed, or passing; before committing or opening a pull request; and whenever a claim of…
testing
Writing effective tests and running them successfully. Covers layer-specific mocking rules, test design principles, debugging failures, and flaky test management. Use when writing tests, reviewing test quality, or debugging test failures.
run-smoke-tests
Run Playwright smoke tests, debug failures, and verify fixes. Use for smoke, e2e, Playwright, or pre-ship browser verification.
bootstrap-solution
Bootstrap or guide a reproducible .NET solution with explicit F# or C# language choice, SDK selection, project layout, test project setup, and initial validation commands.
testing-lint-workflow
Plan, run, filter, and triage Android tests and lint, including local unit tests, instrumentation and Compose UI test handoffs, Gradle variant tasks, lint configuration, lint baselines, failure explanations, emulator-aware validation routing, and readable next checks.
build-csharp-project
Build or modify idiomatic C# .NET projects using nullable-aware APIs, records/classes, async/task behavior, analyzer conventions, tests, and repo-local validation.