SRE / on-call
- When to use it
- Operate the service: runbooks, observability design, incident communications, postmortems, and capacity/cost models.
- Covers
- Run and recover the service (7), Decide what to build (1)
- Where you decide
- G4 human — operate → learn
- Size
- 13 skills · 1 loop · 1 gate, 1 needs a person
npx skilldrop-cli install --pack sre-oncall
Installs 13 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack sre-oncall
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install sre-oncall@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack sre-oncall --ide cursor
Start here: Write the runbook an on-call engineer can follow at 3am
Paste this into your agent:
Write a runbook for our payments-api service: it runs in the Kubernetes namespace payments, depends on Postgres and Stripe, and pages the payments on-call rotation.
- How to tell it worked
- runbook-generator returns a runbook with rollback commands, the common incidents and what to do for each, and an escalation path. Facts you did not give it are marked missing, not invented.
- If nothing happens
- If runbook-generator does not activate, ask for it by name ("use runbook-generator") and check that its folder exists in your skills folder (
~/.claude/skills/by default).
A typical session
When: You are getting a service ready to run, handling an incident, or writing it up afterwards; you can join at whichever stage you are in.
You bring:
- the service: what it does, where it runs, what it depends on, who gets paged
- during or after an incident: the timeline, the Slack thread or pager log, and the known impact
- facts only; the skills mark anything you leave out as missing rather than guessing it
-
- You
- Describe the service and its main user journeys.
- You get
- SLIs and SLOs with error budgets, burn-rate alerts split into page and ticket, and a metrics, logs and traces plan with a cardinality and cost budget.
-
- You
- Give it the service details and the alerts from the plan.
- You get
- A runbook with deploy and rollback steps, what to do for each common incident, escalation, SLOs, dashboards and dependencies, with unknown facts marked missing.
-
- You
- During an incident, say what users are seeing and what stage you are in (detect, mitigate or resolve).
- You get
- Separate updates for the status page, internal stakeholders and execs, each leading with user impact and naming the next update time, with no guessed cause or ETA.
-
- You
- Paste the incident thread, pager timeline and notes once it is over.
- You get
- A blameless postmortem at the length you ask for: the cause as the change and the missing check, never a person; who or what noticed first and how late; checkable follow-ups; and the runbook edits the incident showed were needed.
- You decide
- Gate G4, a human call: PROCEED closes it, PROCEED WITH CONDITIONS closes it with named follow-ups, REVISE sends the deltas back to the runbook.
-
- You
- A few weeks later, export deployments and incidents as CSV and ask whether the postmortem's actions moved anything.
- You get
- Change fail rate, failed deployment recovery time, lead time and deployment frequency computed from the exports, with the weekly trend and the rows it had to skip.
You end with: An observability plan, a runbook tied to its alerts, the incident updates you sent, and a postmortem whose deltas go back into the runbook.
Loops
- operate — Take a shipped service through detection, response, and learning — instrument it, write the runbook, communicate the incident, then feed the postmortem's deltas back into the runbook.
instrument → document → respond → learn [G4]
Compare SRE / on-call with another pack
Skills in this pack (8)
- capacity-cost-model Build a capacity and cost model for a service or feature — sized from a demand driver and its growth curve, not from instance types; unit economics (cost per request/tenant/GB); peak-vs-average and headroom as explicit decisions; cost at 1×/3×/10× with scaling cliffs named; and the forgotten line items (egress, logging, NAT, non-prod) checklisted. Use when the user needs to estimate cloud/infra cost, size capacity for launch or growth, project the bill at scale. For reviewing a bill you already have, use cloud-cost-review. standard
- cloud-cost-review Review actual cloud spend from a cost export (AWS CUR or Data Exports, GCP billing export, Azure cost details) and produce a ranked savings report — idle and unattached resources, oversized instances backed by utilisation evidence, storage tiering, data transfer hot spots, commitment coverage and untagged spend — each finding with a monthly saving computed from the bill, a confidence level and an ease rating. Use when the user shares a cost CSV and says "where are we wasting money", "review our AWS bill", "why did the cloud bill jump this month", "find savings in our GCP/Azure spend", or "should we buy savings plans". standard
- delivery-metrics-report Produce a delivery metrics report for one service from deployment, incident and pull-request exports — the DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time) plus flow metrics (WIP, cycle time p50/p85, throughput), computed by a script with per-week trends and explicit data gaps, then interpreted for what changed and why. Use when the user wants DORA metrics, says "how are we doing on the four keys", "what's our change failure rate", "compute lead time and deploy frequency from this CSV", or "build our delivery metrics report". standard
- incident-comms Draft audience-segmented updates during a live incident — customer status-page posts, internal stakeholder updates, and exec notifications — each leading with user-facing impact, never speculative cause or ETA, always naming the next-update time. Use when an incident is in progress and the user needs a status page post, customer notification, internal update, exec brief, or the resolved/all-clear message. standard
- observability-plan Design an observability plan for a service — user-journey SLIs, SLOs with error budgets, symptom-based burn-rate alerting (page vs ticket, every page actionable and runbook-linked), and a deliberate metrics/logs/traces split with a cardinality and cost budget. Use when the user needs SLOs, alerting design, a monitoring/observability strategy, dashboards, or wants to fix alert fatigue and know what to measure. standard
- postmortem-generator Write a blameless incident postmortem from the raw material (chat scrollback, alert history, timeline, notes) for the audience and length the user names — the cause stated as the change and the gap that let it through, never a person even when the notes name one; who or what noticed first and how late; known kept apart from still-unknown; and follow-up actions that close the gap. Invents no times, figures, owners or severities. Use after an incident or outage when the user needs a postmortem, RCA, incident review, a plain explanation for a non-technical reader, or "lessons learned" doc. standard
- runbook-generator Generate an operational runbook for a service — covering deploy/rollback, common incidents, on-call escalation, SLOs, dashboards, and dependencies. Use when the user is launching a new service, onboarding to on-call, or being asked for "the runbook" by SRE or production-readiness review. standard
- slo-spec 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. Use 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". standard
Included from core (5)
- brief-intake Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- context-graph Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- council-review Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- doc-critique Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- output-hygiene Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard