Stage 5 · operate

SRE / on-call pack reference

Every skill in the SRE / on-call pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

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

Skills

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.

Tier standard · v0.2.0 · SKILL.md · skill page

Use it 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.

A good result:

• Sized from a demand driver with a growth curve, not a chosen instance count. The driver and its source are stated.
• Every cost is a unit cost × a quantity, with the unit price's source and date tagged. A bare monthly total fails.
• Egress, observability, and non-prod lines are present (or explicitly n/a). Their absence is the signature of a model that's 40% low.
• Headroom and peak-vs-average are explicit decisions with reasoning, not absorbed into a rounded number.
• Scaling cliffs are named in the 1×/3×/10× projection. A linear extrapolation that hides a tier jump is a budget trap.
• Outputs are ranges with a lean; the unit-cost-at-scale trend is checked. Rising per-unit cost with growth is flagged as an architecture issue.

Not for:

• Deciding whether to build/buy/invest at all — that's business-case (this can feed its run-cost line)
• Setting the performance/availability targets — that's nfr-spec (this sizes to meet them)
• The migration/rollout sequence — that's migration-plan
• Finding waste in a bill you already pay — that's cloud-cost-review, which works from the cost export
• A fixed-price SaaS seat with no scaling math — just read the price sheet

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.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it 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".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Every amount traces to the script output or to arithmetic shown in the finding. No list prices from memory, and no "industry average" savings percentages.
• Rightsizing needs utilisation evidence. An instance finding without CPU and memory data goes under Evidence needed, not in the ranked table.
• Each finding has a monthly saving, a confidence level and an ease rating, or sits in Evidence needed with what to collect.
• Ranked by saving × ease, and sequenced so waste removal happens before any commitment purchase.
• The month-over-month change is explained by named movers, not described as "costs went up".
• Untagged share is reported both against all spend and against spend that has a resource id, because data transfer and support lines often can't be tagged.
• Excluded lines are stated. Tax, credits, refunds and commitment fees are listed separately so the review doesn't hide credits that mask waste.

Hands off to: observability-plan when logging or metrics ingestion is a top cost hot spot; capacity-cost-model when the user needs the bill projected forward for growth or a launch.

Not for:

• Estimating cost before launch, or projecting at 3× or 10× growth. Use capacity-cost-model.
• Designing telemetry or a logging budget from scratch. Use observability-plan, though this skill flags logging cost as a hot spot.
• Writing up an incident, including a cost spike from a runaway job. Use postmortem-generator.
• Reporting AI tool usage or spend by user. Use ai-usage-report.
• Defining business KPIs for a feature or product. Use success-metrics.

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.

Tier standard · v0.1.4 · SKILL.md · skill page

Use it 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".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Every number comes from the script's output. Nothing is typed, rounded "for readability" into a different value, or estimated to fill a gap.
• Metric names and definitions are stated. The report says it uses DORA's current names and how each one is measured, including where recovery time starts.
• One service per report. A mixed-service file is split with --service or the report says it is aggregated and why that weakens it.
• Distributions, not averages. Lead time, recovery time and cycle time are p50 and p85 (p95 where n allows). A mean of durations is never reported.
• Gaps are named. Skipped rows, unresolved incidents, assumed timezones and uncomputed metrics appear in the report.
• Findings cite a week and a count, and name a next check. "Fail rate is high" with no week and no next step fails.
• No team ranking or performance verdict on individuals. Requests for one are declined with the reason.

Hands off to: postmortem-generator when a failed deployment or incident in the window has no write-up; observability-plan when failed deployment recovery time shows long undetected failures.

Not for:

• Writing up one incident: timeline, impact, contributing factors. Use postmortem-generator.
• Designing SLOs, alerts or dashboards for a service. Use observability-plan.
• Product or business outcome metrics (activation, retention, revenue). Use success-metrics.
• Reporting how people use AI tools. Use ai-usage-report.
• Forecasting infrastructure cost or capacity. Use capacity-cost-model.

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it 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.

A good result:

• First sentence is reader-facing impact, not internal symptom. If a customer needs your architecture diagram to parse it, rewrite.
• Every message names the next-update time (or marks it [set HH:MM]). The cadence promise is the entire contract; an update with no next-time is a dead end.
• Zero retractable claims. No unconfirmed cause, no committed fix-ETA, no premature all-clear. The only time committed is the next update.
• Three audiences are genuinely different, not one text with words swapped. Exec version is business impact + ask; customer version is impact + action; internal version arms the relayer.
• Blameless and forward-safe — no person, no unconfirmed vendor blame, nothing you wouldn't want screenshotted.
• Resolve messages tell still-affected users what to do and promise the postmortem for SEV1/2.

Hands off to: postmortem-generator when the incident is resolved.

Not for:

• The incident is over and you're analyzing it — that's postmortem-generator
• How to technically mitigate — that's the runbook-generator runbook
• A planned-maintenance notice (no failure, no pressure) — a normal scheduled-comms template, not this
• Pre-writing a generic incident-comms policy — this drafts live messages; the policy is a runbook section

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user needs SLOs, alerting design, a monitoring/observability strategy, dashboards, or wants to fix alert fatigue and know what to measure.

A good result:

• SLIs measure user experience (good/valid events), not resource utilization. Latency SLIs are threshold counts at a percentile, never averages.
• Every SLO has an error budget in human terms and a policy for when it's spent. A target with no budget consequence is decoration.
• Pages are actionable, symptom-based, and runbook-linked. If a page doesn't require an immediate human action, it's a ticket — the plan re-tiers it.
• Burn-rate alerting is used, not static "CPU > 80%" thresholds, for SLO-backed surfaces.
• The three pillars are split by purpose, with high-cardinality identifiers kept off metrics. Logs are structured and budgeted.
• A cardinality/cost budget exists. Observability without a cost ceiling becomes the surprise invoice.
• Dashboards are defined by the question they answer, not by quantity.

Hands off to: runbook-generator when the alerts are defined and each needs a procedure; incident-comms when detection fired and an audience needs telling.

Not for:

• Business/product success metrics — that's success-metrics
• Customer/stakeholder comms during an outage — that's incident-comms
• The post-incident analysis — that's postmortem-generator
• The one-line observability requirement in a spec — that's nfr-spec; this is the full design beneath it

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.

Tier standard · v0.2.0 · SKILL.md · skill page

A good result:

• No person is named as a cause. Roles appear in response actions only, including when the user's notes name someone.
• Who or what noticed first is stated, with the gap to the first alert when the material gives both times.
• Known and still-open are kept apart.
• Causes are conditions, not "human error", and come only from the material.
• Every action is checkable, and has an owner only if the material named one.
• Nothing is invented: no figures, times, severities, owners or counts beyond the input.
• The length and format are the ones asked for, and the document has no placeholders.

Hands off to: runbook-generator when the postmortem produced runbook deltas.

Not for:

• During the incident — mitigate first; live updates to stakeholders are incident-comms
• A performance-management record — the document is blameless by design; using it to blame kills honest reporting
• A project retrospective with no production incident
• Writing the runbook itself — hand the runbook changes to runbook-generator

runbook-generator

Generate an operational runbook for a service — covering deploy/rollback, common incidents, on-call escalation, SLOs, dashboards, and dependencies.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user is launching a new service, onboarding to on-call, or being asked for "the runbook" by SRE or production-readiness review.

A good result:

• Owner info is current. Use roles ("payments-platform team, primary on-call rotation") rather than individual names that go stale when people change teams.
• Every alert listed has a response. A "what to do when this alert fires" section that doesn't cover all the alerts is worse than no section.
• Rollback is one command, or three steps max. If rollback is complicated, write a script and link to it.
• No "TBD" left in the doc when it's published. Move TBDs to a "known gaps" section so they're explicit, not hidden.

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use 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".

Needs: Python 3 for its scripts (standard library only).

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].

Hands off to: observability-plan when the SLIs are agreed and the telemetry to produce them doesn't exist yet; runbook-generator when the burn-rate alerts are defined and each page needs a procedure.

Not for:

• 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

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.

Cap: 3 returns before BLOCKED. LOOP.md

Included from core

Installed with this pack. Details: Core pack reference.

• 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.
• 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.
• 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."
• 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.
• 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.

Edit this page on GitHub · View source