Use slo-spec

Define service level objectives for a service from its critical user journeys

Define service level objectives for a service from its critical user journeys — each SLI a good-events / valid-events ratio with both sides defined and measured where the user feels it, a target set from user need and history (checked against dependency SLOs), the error budget computed in minutes and bad requests at current traffic, multi-window burn-rate alerts with the budget consumed when each fires, low-traffic handling, and an error-budget policy with owners.

Reach for it when the user asks to "define SLOs", "write our SLIs", "how much error budget do we have", "what burn-rate alerts should page", "is 99.99% realistic", or "write an error-budget policy".

Install it

npx skilldrop-cli install slo-spec                 # Claude Code, your user folder
npx skilldrop-cli install slo-spec --project       # Claude Code, this repo
npx skilldrop-cli install slo-spec --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the SRE / on-call pack: --pack sre-oncall installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

"Define SLOs for our checkout service: which SLIs, what targets, and the error budget"
"How much error budget is 99.9% over 28 days if we do 3 million requests a day?"
"What burn-rate alerts should page us for a 99.95% availability SLO?"
"Product wants 99.99% for the payments API. Is that realistic when our card processor only promises 99.9%?"
"Write an error-budget policy: what happens when our SLO budget runs out"

Requests like these belong to a different skill, so it shouldn't answer them:

"List the non-functional requirements for the new booking feature: latency, availability, data retention, accessibility"
"What should we instrument in the order service, and which dashboards and log fields do we need?"
"Write the on-call runbook for the payments service, including rollback and escalation"

If another skill answers instead, ask for this one by name: "use slo-spec".

Check what you get

A good result:

2–4 journeys, each with an SLI written as good / valid events, both sides defined, including what's excluded from valid.
The measurement point is named and can see what the user waits for — including queue time on async paths.
No target is 100%, none is five nines without a reason in the input, and none sits above the hard dependencies' combined SLO without naming the redundancy it needs.
Every budget is in minutes and bad requests at stated traffic, matching the script output.
Alerts are burn-rate rows with long and short windows, each with the trip rate, the budget consumed at fire and the time to exhaustion.
Low-traffic journeys are flagged with the count that makes them noisy and get a different method, with the reason.
The policy names owners, thresholds, the freeze rule, the exception route and the dependency case.
Nothing in it is invented: traffic, history, dependency SLOs and people all come from the input or are tagged [assumption].

See a worked example

ticket booking

Use something else when

The full set of non-functional targets for a design — latency, durability, privacy, cost — that's nfr-spec
What to instrument, metrics/logs/traces split, cardinality, dashboards — that's observability-plan
The step-by-step procedure when an alert fires — that's runbook-generator
Deployment frequency, change fail rate, lead time — that's delivery-metrics-report

SKILL.md, the instructions the agent reads
Its page on the site
Related: delivery-metrics-report, nfr-spec, observability-plan, runbook-generator

Edit this page on GitHub · View source