How to use the SRE Engineer agent skill

What is an agent skill and what does this one do?

An agent skill is a folder containing a SKILL.md file and optional reference files. When the skill is installed and a request matches its description, the agent loads these instructions and follows them for that task. This particular skill is built around the SRE workflow: assess reliability, define SLOs, verify that targets reflect user expectations, implement monitoring, automate toil, and test resilience with chaos experiments.

In practice the agent can help you define measurable SLOs and the indicators behind them, calculate how much failure a target allows (the error budget), and propose policies such as freezing non-critical releases when the budget is used up. It can also draft Prometheus alerting rules and PromQL queries, blameless postmortem and incident procedures, chaos experiments, and small automation scripts.

• SLO and SLI definitions with targets, such as 99.9% availability
• Error budget calculations and budget status levels
• Golden signal PromQL queries for latency, traffic, errors and saturation
• Multiwindow burn-rate Prometheus alerting rules
• Toil measurement and automation scripts
• Incident severity levels and chaos engineering guidance

Install the sre-engineer skill

Download the sre-engineer ZIP from the download button on this page. Unzip it into one of two locations. For a personal install available to all your projects, unzip it into ~/.claude/skills/. For a single project, unzip it into that project's .claude/skills/ folder so it is shared with everyone working in that repository.

If you use the Claude apps instead of the file system, open Settings, go to Capabilities, and upload the skill under Skills. Check that the folder contains SKILL.md and the references directory after unzipping, because the agent loads the reference guides from there.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your repository
• Claude apps: Settings → Capabilities → Skills, then upload the skill

Trigger the skill with natural requests

You do not need a special command. The skill is selected when your request matches its description, which covers SLIs and SLOs, error budgets, incident management, chaos engineering, toil reduction and capacity planning. Name the service, its traffic and the tools you use, because the output assumes Prometheus-style monitoring and Kubernetes where relevant.

Good requests state the goal and the context. Vague requests produce generic guidance.

• "Define SLOs and SLIs for our checkout API. It serves HTTP traffic, with metrics in Prometheus."
• "Calculate the error budget for a 99.9% availability target over 30 days and propose a release policy."
• "Write Prometheus burn-rate alerts for our payments service, with runbook links for each alert."
• "Draft a blameless postmortem template and a SEV1 incident response procedure."
• "Find repetitive on-call tasks in our team's notes and propose automation for the top two."

Example outputs you can expect

For an SLO request, the agent is expected to give the target, the SLI that measures it and the budget that follows. The skill's own worked example shows a 99.9% availability SLO over 30 days, which allows about 43.2 minutes of downtime per month. With 10 million requests a month, the request-based budget is 10,000 failed requests. If 5,000 errors occur in the first week, half the budget is gone in a quarter of the window, which triggers the policy to freeze non-critical releases.

For alerting, the skill includes a fast-burn rule that fires when the error ratio exceeds 14.4 times the budget rate over both a 1-hour and a 5-minute window, and a slower warning rule over 6 hours. The golden signal examples show a 99th percentile latency query, a request rate query, an error ratio query and a CPU throttling ratio for saturation.

Review the outputs before you use them

Treat every generated threshold, target and query as a draft. The alert examples use placeholder runbook URLs on an internal wiki, and the SLO targets must reflect what your users actually expect. Check PromQL metric names against what your exporters really emit, since the examples assume metrics such as http_requests_total and http_request_duration_seconds_bucket.

Each output should also be checked against your own incident process and any legal or compliance commitments. The guidance is generic.

Safety notes for the sample scripts

The skill includes a Python auto-remediation script. It queries a Prometheus server at an internal address and, if the error rate is above 5%, runs kubectl rollout restart on a deployment. This means it uses the network and runs scripts. A wrong threshold, a wrong namespace or a wrong Prometheus target could restart deployments unexpectedly.

Do not run it against live clusters without reading it and testing it in a non-production environment first. Make sure your kubeconfig points where you intend, and confirm the Prometheus address before you run it.

• Requires Python 3, Kubernetes with kubectl, and network access to a Prometheus server
• Hardcoded Prometheus address is http://prometheus:9090 and must be changed for your environment
• Usage takes three arguments: service, namespace and deployment

Tips for better results

Give the agent real numbers: current SLO, traffic volume, recent incident history and which dashboards exist. The skill is designed to measure toil and track its reduction, so a rough estimate of weekly repetitive tasks gives it something to work with. Ask it to explain the reliability impact of each recommendation, since the skill is meant to include that in its output.

• Start with one service rather than the whole platform
• Ask for the error budget calculation alongside any SLO
• Ask for the runbook for each alert, because the skill is designed to avoid alerts without actionable runbooks