10 Best Claude Skills for DevOps and SRE
Use Claude skills for incidents, rollbacks, SLOs, alerts, dashboards, logs, traces, containers, CI, and safer releases.
A practical Claude SRE toolkit spans the full operational loop: define reliability with slo-definer, instrument logs and traces, tune alerts and dashboards, plan canaries and rollbacks, and turn incidents into corrective action with incident-postmortem-writer. Keep production mutations behind explicit human approval.
Key takeaways
- Use Claude skills to prepare and analyze operational work, but require explicit approval for production changes.
- SLOs should drive alerts and dashboards; otherwise observability becomes a collection of unrelated signals.
- Every risky release needs both a rollout plan and a rollback decision with measurable triggers.
- Incident-postmortem-writer separates evidence, impact, contributing conditions, and corrective actions without assigning blame.
- Logging and tracing skills are complementary: logs explain events while traces connect latency and failures across services.
The best Claude skills for DevOps and SRE support a cycle: set reliability targets, collect useful signals, detect actionable failures, release gradually, recover safely, and learn from incidents. Installing only a Docker or CI helper leaves most of that cycle uncovered.
The skills below produce plans and artifacts you can review. Production actions should remain explicit, scoped, and human-approved.
| Skill | Best for | Main output | Production mutation? |
|---|---|---|---|
| incident-postmortem-writer | Learning after incidents | Evidence-based postmortem | No |
| rollback-plan-writer | Safe recovery planning | Executable rollback plan | No |
| slo-definer | Reliability targets | SLIs, objectives, and budgets | No |
| alerting-rules-tuner | Actionable paging | Tuned alert rules | Config draft |
| dashboard-designer | Operational views | Dashboard specification | Config draft |
| structured-logging-designer | Searchable events | Logging schema and instrumentation | Code edits |
| distributed-tracing-instrumenter | Cross-service latency | Trace instrumentation | Code edits |
| dockerfile-optimizer | Smaller, safer images | Dockerfile improvements | File edits |
| github-actions-optimizer | Faster, safer CI | Workflow improvements | File edits |
| canary-release-planner | Controlled exposure | Staged rollout plan | No |
1. incident-postmortem-writer: learn from evidence
incident-postmortem-writer assembles alerts, logs, tickets, chat timestamps, deploy events, and mitigation records into one timeline. It separates confirmed facts from inference, quantifies impact where possible, identifies contributing conditions, and assigns corrective actions with owners and verification.
Use it after the service is stable. The postmortem is not a live-response substitute and should never fill timeline gaps with invented certainty.
2. rollback-plan-writer: prepare recovery before release
rollback-plan-writer identifies the last known-safe state, compatibility constraints, rollback triggers, responsible owner, exact actions, and post-rollback checks. It explicitly handles changes that cannot be reversed by redeploying an old artifact, including schema migrations and one-way data transformations.
3. slo-definer: decide what reliability means
slo-definer translates a user journey into a measurable service-level indicator, target, window, and error budget. Good SLOs create a shared basis for alert thresholds and release decisions; they are not vanity uptime numbers detached from user experience.
4. alerting-rules-tuner: make pages actionable
alerting-rules-tuner reviews noisy or late alerts against impact and operator action. It adjusts windows, thresholds, grouping, and routing while preserving the signal that indicates an SLO is at risk.
5. dashboard-designer: show decisions, not every metric
dashboard-designer organizes panels around questions: Is the user journey healthy? Where is the failure? What changed? Is the mitigation working? It defines each query, unit, aggregation, time range, and drill-down instead of producing a wall of charts.
6. structured-logging-designer: standardize operational events
structured-logging-designer creates consistent event names and fields, correlation identifiers, severity rules, and redaction boundaries. It improves searchability without encouraging sensitive payload dumps or uncontrolled high-cardinality fields.
7. distributed-tracing-instrumenter: connect service boundaries
distributed-tracing-instrumenter adds spans at meaningful boundaries and propagates context across HTTP, queues, jobs, and database calls. It focuses attributes on diagnosis while avoiding secrets and unbounded dimensions.
8. dockerfile-optimizer: improve build and runtime images
dockerfile-optimizer examines build context, cache layers, multi-stage builds, package installation, user privileges, and runtime contents. It validates the built image instead of assuming a shorter Dockerfile is automatically better.
9. github-actions-optimizer: tighten CI
github-actions-optimizer targets duplicated work, ineffective caches, broad token permissions, unpinned actions, and weak concurrency controls. Use it after measuring which jobs dominate feedback time or when a workflow gains new privileges.
10. canary-release-planner: limit blast radius
canary-release-planner defines stages, cohorts, observation windows, health signals, promotion criteria, stop conditions, and ownership. Pair it with rollback-plan-writer: a controlled rollout still needs a tested way back.
A small-team SRE stack
Start with one skill for each stage: slo-definer, structured-logging-designer, alerting-rules-tuner, rollback-plan-writer, and incident-postmortem-writer.
npx agentscamp add skills/slo-definer
npx agentscamp add skills/structured-logging-designer
npx agentscamp add skills/alerting-rules-tuner
npx agentscamp add skills/rollback-plan-writer
npx agentscamp add skills/incident-postmortem-writerBefore using any generated operational command, verify the environment, target, credentials, expected blast radius, abort condition, and recovery path. Claude can make the procedure clearer; authorization still belongs to the operator.
Frequently asked questions
- What is the best Claude skill for incident response?
- During an incident, use runbook-writer output and existing observability to guide approved actions. After stabilization, incident-postmortem-writer reconstructs the evidence-based timeline and corrective actions. It should not invent missing events.
- Can Claude safely make production changes?
- Production mutations carry high risk. Use these skills for analysis, plans, configuration drafts, and verification commands, then keep deployment, rollback, credential, and infrastructure changes behind explicit human authorization.
- Which skills should a small team install first?
- Start with slo-definer, structured-logging-designer, alerting-rules-tuner, rollback-plan-writer, and incident-postmortem-writer. Together they cover targets, evidence, detection, recovery, and learning.
- Is a canary plan the same as a rollback plan?
- No. A canary plan controls exposure and promotion; a rollback plan defines how to restore a known-safe state, including compatibility checks, triggers, commands, owners, and verification. Use both for risky changes.
Related
- The Best Claude Skills to Install in 2026A skills-only tour of the AgentsCamp library — the Claude Code skills that earn a permanent slot, organized by the job they do.
- Incident Postmortem WriterTurn incident notes, alerts, chat logs, deploy history, and traces into a blameless, evidence-backed postmortem with impact, timeline, contributing conditions, detection and response gaps, and owned corrective actions. Use after a production incident, failed deployment, security event, or near miss when the team needs a durable learning document rather than a root-cause guess.
- Rollback Plan WriterWrite a tested rollback and forward-recovery plan for a release, including triggers, commands, compatibility constraints, data handling, verification, ownership, and stop conditions. Use before high-risk deploys, schema or configuration changes, dependency upgrades, model or provider migrations, feature launches, and any release where 'just redeploy the old version' is incomplete or unsafe.
- SLO DefinerTurn a vague reliability goal into concrete SLIs, SLOs, an error budget, and burn-rate alerts — service-level indicators measured at the user-facing boundary, targets over a rolling window, and a written policy for what happens when the budget runs out. Use when a service has no defined reliability target, when on-call is noisy and alert-fatigued, or before you commit to an SLA you can't measure.
- Alerting Rules TunerCut alert noise and make every page mean something — rewrite alerting rules to fire on user-felt symptoms (error rate, latency SLO burn, failed requests) instead of causes (high CPU, full disk), with duration windows and severity routing so only urgent, actionable conditions reach a human. Use when on-call is fatigued by low-value pages, when real incidents get missed in the noise, or when alerts fire on causes rather than impact.
- Canary Release PlannerDesign a canary / progressive rollout so a bad release reaches 1% of users instead of 100% — staged traffic with bake times, gating metrics compared against the concurrently-running stable baseline, and automated promote-or-rollback. Use when shipping a risky change, when you want automatic rollback on regression, or when moving off all-at-once deploys.