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 samibs/skillfoundry --skill deliverygit clone --depth 1 https://github.com/samibs/skillfoundryWrote 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/samibs/skillfoundry/delivery)<a href="https://agentmods.dev/skills/samibs/skillfoundry/delivery"><img src="https://agentmods.dev/badge/skills/samibs/skillfoundry/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/samibs/skillfoundry/delivery"><img src="https://agentmods.dev/badge/skills/samibs/skillfoundry/delivery.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.00007 | $0.01045 |
| Opus 5.5 | $0.00003 | $0.00418 |
| Sonnet 5.5 | $0.00001 | $0.00209 |
| Haiku 4.5 | $0.00001 | $0.00104 |
Grade A, and why
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 14d 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 — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
description: "Use before implementing any change to decide how much validation it warrants, and after to decide when you are done: deterministic LOW/MEDIUM/HIGH delivery budgets, evidence reuse (already proven + unchanged = do not prove again), validation deduplication across parallel agents, scoped test selection, measured change impact, and objective stop conditions. Triggers: 'do I need to run the full suite', a small change about to trigger repository-wide validation, several agents each re-running the same tests, 'is this task actually finished', repeated repository archaeology. Do NOT use for: deciding WHAT to build (use /prd or /forge), running the gates themselves (use /gate or /verify), or proving a change shipped (use /mission)."
/delivery — Delivery Efficiency
Canonical policy:
agents/_delivery-efficiency.md· Full docs:docs/DELIVERY-EFFICIENCY.md
Do not perform more engineering activity than is necessary to prove the requested change correct. A shorter execution is not automatically better. A longer execution is not automatically safer. The correct execution is the minimum defensible one.
Agent effectiveness = accepted useful change / (elapsed time × compute cost × human attention)
What it prevents
| Waste | How it is stopped |
|---|---|
| A typo fix triggering the repository-wide suite | LOW budget caps scope at smoke; full is unreachable from a budget alone |
| Re-running a check that already passed | Evidence keyed to the content hash of the files it depended on |
| Re-running one that already failed | FIX_FIRST — fix the cause, don't reproduce the failure |
| Three agents running the same suite | The first claims it; the others consume its evidence |
| Re-deriving the architecture every task | Shared mission facts, with confidence levels |
Escalating to full after fixing a test |
Escalation needs evidence of wider impact, not a passing fix |
| Re-reviewing an already-proven diff | DeliveryComplete is objective, and says what not to do next |
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.
- 14d ago First seen · 107 lines · 7 tokens per session scan A 4e7fe1d53108
delivery is a skill published in the GitHub repository samibs/skillfoundry (12 stars, last pushed 14d ago), licensed MIT. It adds 7 tokens to every session and 1,045 once invoked, about $0.0000 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-10-03.
Other skills, from other repositories
ring:running-dev-cycle
Running the backend dev cycle: implements every task in a rolling-wave plan.md (ring:writing-plans format) for a Go/TS service, driving specialist agents through Gate 0 implementation/TDD, Gate 8 parallel review, and Gate 9 validation per epic, elaborating later phases at each phase boundary. Use when starting or…
ring:test-driven-development
Enforcing the RED-GREEN-REFACTOR loop: write one failing test and watch it fail, write minimal code to pass, then refactor green. Use when starting implementation of a new feature or bugfix, or writing any new production code. Requires pasted failure output as proof of RED; code written before its test must be…
ring:writing-skills
Writing or editing a Ring skill: SKILL.md structure, frontmatter and Agent-Search-Optimization rules, token-efficiency targets, and bulletproofing (Iron Law, rationalization tables, Red Flags) so discipline-enforcing skills resist excuses. Use when creating or revising a skill. Delegates pressure-testing to…
ring:detecting-goroutine-leaks
Detecting goroutine leaks in Go: greps for goroutine patterns, audits goleak coverage (VerifyTestMain/VerifyNone), runs goleak, and dispatches ring:backend-go to fix leaks and add regression tests. Use after implementation or during review when code spawns goroutines or a leak is suspected. Runs before…
ring:creating-worktrees
Creating an isolated git worktree for parallel branch work: selects the directory by priority order, verifies/adds .gitignore safety, auto-installs the detected toolchain's dependencies, runs a baseline test, and reports readiness. Use before a feature that needs isolation from the main workspace or before executing…
ring:validating-acceptance-criteria
Validating a completed task against its acceptance criteria, mapping each AC to evidence, and gating completion on explicit user sign-off (self-approval prohibited). Gate 5 of ring:running-dev-cycle / ring:running-dev-cycle-frontend, run at task cadence after ring:reviewing-code. Use when implementation and tests are…