How do I install the Sre skill?

Run npx skillmds@latest add travisleeeeee/sre in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Sre skill do?

🎯 Your Core Mission It is listed under Coding & Dev Tools on SkillMD.

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Sre?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

TravisLeeeeee (@travisleeeeee) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Sre by travisleeeeee — Agent Skill

Name: Sre
Rating: 4.2 (5 reviews)
Author: TravisLeeeeee

File contents

🎯 Your Core Mission

Build and maintain reliable production systems through engineering, not heroics:

SLOs & error budgets — Define what "reliable enough" means, measure it, act on it
Observability — Logs, metrics, traces that answer "why is this broken?" in minutes
Toil reduction — Automate repetitive operational work systematically
Chaos engineering — Proactively find weaknesses before users do
Capacity planning — Right-size resources based on data, not guesses

📋 SLO Framework

# SLO Definition
service: payment-api
slos:
  - name: Availability
    description: Successful responses to valid requests
    sli: count(status < 500) / count(total)
    target: 99.95%
    window: 30d
    burn_rate_alerts:
      - severity: critical
        short_window: 5m
        long_window: 1h
        factor: 14.4
      - severity: warning
        short_window: 30m
        long_window: 6h
        factor: 6

  - name: Latency
    description: Request duration at p99
    sli: count(duration < 300ms) / count(total)
    target: 99%
    window: 30d

🔭 Observability Stack

The Three Pillars

Pillar	Purpose	Key Questions
Metrics	Trends, alerting, SLO tracking	Is the system healthy? Is the error budget burning?
Logs	Event details, debugging	What happened at 14:32:07?
Traces	Request flow across services	Where is the latency? Which service failed?

Golden Signals

Latency — Duration of requests (distinguish success vs error latency)
Traffic — Requests per second, concurrent users
Errors — Error rate by type (5xx, timeout, business logic)
Saturation — CPU, memory, queue depth, connection pool usage

🔥 Incident Response Integration

Severity based on SLO impact, not gut feeling
Automated runbooks for known failure modes
Post-incident reviews focused on systemic fixes
Track MTTR, not just MTBF

---name: sredescription: 🎯 Your Core Mission---## 🎯 Your Core MissionBuild and maintain reliable production systems through engineering, not heroics:1. **SLOs & error budgets** — Define what "reliable enough" means, measure it, act on it2. **Observability** — Logs, metrics, traces that answer "why is this broken?" in minutes3. **Toil reduction** — Automate repetitive operational work systematically4. **Chaos engineering** — Proactively find weaknesses before users do5. **Capacity planning** — Right-size resources based on data, not guesses## 📋 SLO Framework```yaml# SLO Definitionservice: payment-apislos: - name: Availability description: Successful responses to valid requests sli: count(status < 500) / count(total) target: 99.95% window: 30d burn_rate_alerts: - severity: critical short_window: 5m long_window: 1h factor: 14.4 - severity: warning short_window: 30m long_window: 6h factor: 6 - name: Latency description: Request duration at p99 sli: count(duration < 300ms) / count(total) target: 99% window: 30d```## 🔭 Observability Stack### The Three Pillars| Pillar | Purpose | Key Questions ||--------|---------|---------------|| **Metrics** | Trends, alerting, SLO tracking | Is the system healthy? Is the error budget burning? || **Logs** | Event details, debugging | What happened at 14:32:07? || **Traces** | Request flow across services | Where is the latency? Which service failed? |### Golden Signals- **Latency** — Duration of requests (distinguish success vs error latency)- **Traffic** — Requests per second, concurrent users- **Errors** — Error rate by type (5xx, timeout, business logic)- **Saturation** — CPU, memory, queue depth, connection pool usage## 🔥 Incident Response Integration- Severity based on SLO impact, not gut feeling- Automated runbooks for known failure modes- Post-incident reviews focused on systemic fixes- Track MTTR, not just MTBF

Frequently asked questions

Sre