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 fattain-naime/engineering-docs --skill slo-error-budget-documentgit clone --depth 1 https://github.com/fattain-naime/engineering-docsWrote 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/fattain-naime/engineering-docs/slo-error-budget-document)<a href="https://agentmods.dev/skills/fattain-naime/engineering-docs/slo-error-budget-document"><img src="https://agentmods.dev/badge/skills/fattain-naime/engineering-docs/slo-error-budget-document/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/fattain-naime/engineering-docs/slo-error-budget-document"><img src="https://agentmods.dev/badge/skills/fattain-naime/engineering-docs/slo-error-budget-document.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00071 | $0.04244 |
| Opus 5.5 | $0.00028 | $0.01698 |
| Sonnet 5.5 | $0.00014 | $0.00849 |
| Haiku 4.5 | $0.00007 | $0.00424 |
Grade A, and why
slo-error-budget-document 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 — 267 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Produce an SLO document that defines exactly how a service's reliability is measured (SLIs), what target is acceptable (SLOs), how much unreliability the team is allowed to spend before it must stop shipping and fix things (error budget), and what alerts fire as that budget burns.
"The service should be reliable" is not a target - it is an opinion. This skill turns it into a number everyone can point to, measure against, and hold each other to.
Input
Works best with: The name of the service or API being measured. Also valuable: Existing incident history, any external SLA already promised to customers, current monitoring/metrics stack, the business cost of downtime.
Example invocation: Define SLOs for our checkout API. We currently have no formal target - customers complain when checkout is slow but we've never quantified it. We use Prometheus/Grafana for metrics. We are not yet contractually bound to any external SLA.
Key Concepts
SLI, SLO, SLA - Not the Same Thing
- SLI (Indicator): A direct measurement of user-facing behavior. E.g., "proportion of successful checkout requests" or "proportion of API requests completing under 300ms."
- SLO (Objective): The internal target for an SLI over a window. E.g., "99.9% of checkout requests succeed, measured over a rolling 30 days."
- SLA (Agreement): An external, often contractual, promise - usually looser than the internal SLO, with financial penalties or credits attached to missing it. Never set the SLA equal to the SLO; the gap is the buffer that lets you miss the SLO occasionally without breaching a customer contract.
Why Not 100%
100% reliability is the wrong target for almost every system: it is disproportionately expensive to approach, and it eliminates all room for planned risk - deploys, migrations, experiments. The error budget (1 - SLO) is the amount of unreliability the business has explicitly decided is an acceptable cost of moving fast.
Multi-Window, Multi-Burn-Rate Alerting (Google SRE Workbook)
A single "error rate > X%" alert either fires too late for fast, severe burns or too often for slow, minor ones. Use multiple burn-rate windows:
What ships with it
1 file 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.
- 1mo ago First seen · 267 lines · 71 tokens per session scan A 37d11c542c31
slo-error-budget-document is a skill published in the GitHub repository fattain-naime/engineering-docs (6 stars, last pushed 3d ago), licensed MIT. It adds 71 tokens to every session and 4,244 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
companion-clis
Companion CLIs for Runpod workflows — HuggingFace, GitHub, Docker, and AWS.
cloud-deployment-routing-workflow
Choose a cloud deployment path before implementation. Route AWS work to the official AWS Agent Toolkit and Azure work to Microsoft's Azure Skills plugin while keeping credentials, regions, and mutation boundaries explicit.
macos-distribution-workflow
Inspect, prepare, validate, and troubleshoot exported macOS distribution artifacts. Use when checking signing identities, entitlements, hardened runtime, nested code, Gatekeeper, notarization readiness/results, stapling, or distribution-only launch failures.
prepare-isolated-analysis-lab
Prepare a verified disposable Linux or macOS analysis lab from an approved isolation decision. Use before active research to control host integration, networking, baseline, monitoring, evidence export, reset, and teardown.
flash
Write code locally, iterate with flash dev — it runs your functions on remote Runpod GPUs/CPUs with hot-reload and live worker logs — then flash deploy to ship. Endpoint handles provisioning.
runpodctl
Runpod CLI to manage your GPU workloads.