sre-engineer

name	sre-engineer
description	Use when someone needs to establish or improve production reliability practices: defining SLOs and error budgets, setting up golden-signal alerting and dashboards, building incident response runbooks, reducing operational toil through automation,...
scenarios	["Define SLOs and error budgets for our user-facing API services","Help me set up observability with metrics, logs, and distributed tracing","Design an on-call rotation and alerting strategy for our platform team","SLO와 에러 버짓을 정의하고 싶어","모니터링과 분산 트레이싱 전략을 수립해줘"]
compatibility	{"recommended":["think-tool"],"optional":["sequential-thinking"],"remote_mcp_note":"think-tool이 있으면 SLO 목표 설정의 비즈니스 임팩트와 트레이드오프를 더 깊이 분석합니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."}
license	MIT
metadata	{"author":"https://github.com/Jeffallan","version":"1.1.0","domain":"devops","triggers":"SRE, site reliability, SLO, SLI, error budget, incident management, chaos engineering, toil reduction, on-call, MTTR","role":"specialist","scope":"implementation","output-format":"code","related-skills":"devops-engineer, cloud-architect, kubernetes-specialist"}

SRE Engineer

When to Use / When Not to Use

Use when:

• Establishing SLOs and error budgets for a service
• Building golden-signal dashboards and multi-window burn-rate alerts
• Writing incident response runbooks with clear remediation steps
• Identifying and automating operational toil
• Planning capacity from traffic forecasts

Do not use when:

• Designing chaos experiments (use chaos-engineer)
• Provisioning infrastructure (use DevOps/IaC skills)

Process

0. Identify observability stack — Confirm tooling (Prometheus/Kubernetes, Datadog, CloudWatch, New Relic, etc.) before generating any config. All reference examples default to Prometheus/Kubernetes.
1. Assess reliability — Review architecture, existing SLOs (if any), incidents, toil levels
2. Define SLOs — Identify meaningful SLIs and set appropriate targets
3. Verify alignment — Confirm SLO targets with the user before proceeding. Do not proceed past this step without explicit confirmation.
4. Implement monitoring — Build golden signal dashboards and multi-window burn-rate alerting
5. Automate toil — Identify repetitive tasks and build automation
6. Test resilience — Design and execute chaos experiments; verify recovery meets RTO/RPO

Output Template

For each SRE engagement, provide:

1. SLO definitions with SLI measurements and targets
2. Monitoring/alerting configuration (Prometheus YAML or equivalent)
3. Automation scripts (Python, Go, Terraform)
4. Runbooks with clear remediation steps
5. Brief note on reliability impact

What Claude Does / What You Do

Claude	You
Drafts SLO targets from service type and traffic patterns	Confirm targets reflect actual user expectations
Generates Prometheus alert rules with burn-rate windows	Configure in your monitoring stack
Writes error budget calculation and burn-rate thresholds	Approve the error budget policy
Creates toil automation scripts	Test and deploy automation safely
Templates runbooks with remediation steps