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 agentmods add skills/fattain-naime/engineering-docs/slo-error-budget-documentnpx 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.svg" alt="Measured on agentmods" 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 | $0.00071 | $0.04244 |
| Opus 5 | $0.00036 | $0.02122 |
| Sonnet 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 4d 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.
- 4d 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 (4 stars, last pushed 19d ago), licensed MIT. It adds 71 tokens to every session and 4,244 once invoked, about $0.0004 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-08-31.
Other skills, from other repositories
cloud-architect
Designs cloud architectures, creates migration plans, generates cost optimization recommendations, and produces disaster recovery strategies across AWS, Azure, and GCP. Use when designing cloud architectures, planning migrations, or optimizing multi-cloud deployments. Invoke for Well-Architected Framework, cost…
rule
Skill "rule" from x-cmd/x-cmd, covering rule — rules to rule, 核心命令, 规则文件格式, 示例 and 验证规则文件格式.
cve
Look up CVE records via x cve — cached, zero-API-key, daily xz TSV. Load for cve, vulnerability id, kev, epss, nvd, cvelist, or security advisory.
azmon-mirroredcatalogs-operations-cli
Brings Azure Monitor, Application Insights, and Log Analytics telemetry into Fabric as Eventhouse external delta tables and correlates it with business data. Use to onboard observability data, judge whether latency or availability affected revenue, or build a Real-Time dashboard and Operations Agent over it.
atmos-auth
Authentication and identity management: providers (SSO/SAML/OIDC/GCP/Atmos Pro), identities, keyring, identity chaining, login/exec/shell/console, and github/sts for private GitHub access.
terraform-search-import
Discover existing cloud resources using Terraform Search queries and bulk import them into Terraform management. Use when bringing unmanaged infrastructure under Terraform control, auditing cloud resources, or migrating to IaC.