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 magnus919/agent-skills --skill verified-deliverygit clone --depth 1 https://github.com/magnus919/agent-skillsWrote 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/magnus919/agent-skills/verified-delivery)<a href="https://agentmods.dev/skills/magnus919/agent-skills/verified-delivery"><img src="https://agentmods.dev/badge/skills/magnus919/agent-skills/verified-delivery/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/magnus919/agent-skills/verified-delivery"><img src="https://agentmods.dev/badge/skills/magnus919/agent-skills/verified-delivery.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 35 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 119 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00123 | $0.02237 |
| Opus 5 | $0.00062 | $0.01118 |
| Sonnet 5 | $0.00025 | $0.00447 |
| Haiku 4.5 | $0.00012 | $0.00224 |
Grade A, and why
verified-delivery 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 6d 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 — 213 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verified Delivery
Carry an authorized change from implementation through merge and post-merge verification through a sequence of live-state gates. Every gate is verified against the actual state of the repository, PR, CI, and review system before the next step runs, and every gate verdict is bound to the exact head SHA it was verified on. Because hard limits (tool-call budgets, context exhaustion, worker replacement, session interruptions) can end the work before the delivery boundary is reached, this skill defines a durable interruption handoff and a resumption protocol that treats the next re-entry as a resume of the same directive — not a request to restate it.
Authorization boundary
Delivery proceeds only under an explicit user directive that names the change and the gates it authorizes. Never infer permission from context, tone, or a partial handoff.
Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation.
Apply this confirmation before the first mutation, including on resumption. The target names the repository and PR when one exists, the scope names the next authorized gated steps, and the rollback path states how the next mutation can be reversed or contained. A handoff records this confirmation; it does not widen it.
- The directive states which gated steps are authorized (for example: open a PR, merge when CI is green and reviews are satisfied, verify post-merge).
- Steps outside the stated boundary stop at their gate with the exact missing authorization reported. Asking the user for an explicit new decision is the correct response to a gap; acting anyway is not.
- The authorization travels with the work: it is restated verbatim in the interruption handoff (below) so a resumed session inherits the same boundary, never a wider one.
Preserved boundaries at every gate:
- Merge boundary — merge only when merge is explicitly authorized and the CI and review gates pass on the exact head being merged.
- Review boundary — address review feedback inside a bounded loop; never force past unresolved review objections.
- Security boundary — security findings from CI or review are gates, not warnings; they are never bypassed, weakened, or retried until clean by suppression.
- Exact-head boundary — all gate evidence binds to the exact head SHA. A moved head invalidates prior evidence until it is re-verified on the new head.
- Non-convergence boundary — after three non-converging fix or review passes at any gate, stop and report the evidence.
- Post-merge verification boundary — the delivery is not complete until the merged state is verified after the merge.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 6d ago First seen · 213 lines · 123 tokens per session scan A 6b495e821d7c
verified-delivery is a skill published in the GitHub repository magnus919/agent-skills (76 stars, last pushed today), licensed MIT. It adds 123 tokens to every session and 2,237 once invoked, about $0.0006 per session on Opus 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-05.
Other skills, from other repositories
github-release-management
Comprehensive GitHub release orchestration with AI swarm coordination for automated versioning, testing, deployment, and rollback management.
taiyi-integration
A project workflow skill for closing a TaiyiForge change and recording it in a CHANGELOG.md file. It checks review results, tests, and the state of the working tree before archiving the change.
ship
Enter the Ship phase of CocoBrew. Reads review.md approval, generates structured commit, creates semantic version tag, optionally creates PR via gh CLI, and records deployment details. Requires approved review.
swarm-migrate
Cross-repo migration swarm — one coordinator + N parallel subagents (one per target repo) that apply the same transformation, open PRs, wait for CI, and report back to a shared JSON ledger. Coordinator handles topology, conflict auto-rebase, and stop-on-novel-failure. Use when bumping a shared dependency, rolling out…
release-management
Automates GitHub releases with semantic versioning, changelog generation from merged PRs, and gh CLI integration. Supports draft, prerelease, and standard release workflows with task-tracked multi-phase execution. Use when creating releases, tagging versions, or publishing changelogs.
release-sync
Syncs latest release content to NotebookLM and HQ Knowledge Base after version tagging. Reads CHANGELOG, CLAUDE.md, and hook README, updates notebook sources, and ingests release digest. Optionally generates podcast from updated knowledge base. Use after tagging a new version to propagate release knowledge.