SLO and Error Budget Skill

Produce a complete, implementable SLO document for a service — covering what to measure, what target to set, how to calculate the error budget, and what to do when it burns.

A good SLO is not a target to hit. It is an agreement about what reliability means for your users — and a framework for making principled trade-offs between reliability and velocity.

Where this sits — the frame of the spine

This is the governor of the incident-response spine: slo-error-budget (frame) → /debugging-log-analyser → /incident-postmortem → /oncall-runbook. It sets the error budget the whole loop runs inside — the objective forcing function that later decides whether a postmortem's action items get done now (budget spent) or deferred (budget healthy). Shared terms (SLO, error budget, incident, action item) are defined once in docs/craft/incident-response.md.

The loop

An SLO fails when it's aspirational instead of user-derived, or when the budget has no teeth. Phase 1 is load-bearing: a target picked from "100% minus a bit" defends nothing.