slo-error-budget-document

## 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 m...