Stage 5 · operate

Use the SRE / on-call pack

Install the SRE / on-call pack, run its first task, and follow a typical session step by step.

Operate the service: runbooks, observability design, incident communications, postmortems, and capacity/cost models.

Reach for it 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.

1. Install it

npx skilldrop-cli install --pack sre-oncall                 # Claude Code, your user folder
npx skilldrop-cli install --pack sre-oncall --project       # Claude Code, this repo
npx skilldrop-cli install --pack sre-oncall --ide cursor    # or kiro, codex, antigravity, copilot
npx skilldrop-cli install --pack sre-oncall --local         # this repo, hidden from git

In Claude Code you can also add the marketplace once (/plugin marketplace add sananthanarayan/skilldrop) and run /plugin install sre-oncall@skilldrop.

It brings core with it, so the shared skills are there too.

2. Run the first task: 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).

3. A typical session

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
• observability-plan: 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.
• runbook-generator: 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.
• incident-comms: 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.
• postmortem-generator: 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.
• delivery-metrics-report: 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.

4. Run it as a loop

A loop runs the skills in order and stops at each gate for a verdict. Install and start one:

npx skilldrop-cli install --loop --pack sre-oncall

• 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. Say "run the operate loop on this". Stages: instrument → document → respond → learn [G4].

Next

• Every skill in the SRE / on-call pack: what each one makes, needs and hands off to
• The pack's page, with one-click copy for every command
• Upgrade installed skills when a new version ships

Edit this page on GitHub · View source