sre-principles

Guides incident investigations with evidence-based reasoning and structured communication standards.

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/erwinv2k-TKG/AgentesVSC --skill sre-principles-erwinv2k-tkg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sre-principles
Source: https://github.com/erwinv2k-TKG/AgentesVSC/tree/main/packs/incidentfox/local/claude_code_pack/skills/sre-principles
Command: npx skills add https://github.com/erwinv2k-TKG/AgentesVSC --skill sre-principles-erwinv2k-tkg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Incident investigations often suffer from speculation, vague claims, and premature conclusions. This Skill enforces disciplined SRE practices so findings are backed by evidence, confidence levels are stated honestly, and reports follow a consistent structure. ## Core Features & Use Cases - Confidence Calibration: Classify findings as high confidence, likely, possible, or uncertain, and clearly separate observed facts from inferred hypotheses. - Evidence-Based Reasoning: Require every claim to cite specific data such as timestamps, metric values, and error messages, and build chronological incident timelines. - Falsification and Thoroughness: Actively seek contradicting evidence, consider alternative causes, and push past surface symptoms to actionable root causes. - Use Case: During a Kubernetes outage, use these principles to produce a report stating the root cause (e.g., OOMKilled pods from a memory leak in a specific commit), the supporting metrics, ruled-out hypotheses, and concrete remediation steps. ## Quick Start Apply the SRE investigation principles to analyze the current incident and produce a structured root cause report with evidence and confidence levels.

Frequently Asked Questions about sre-principles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good incident root cause analysis report?

Structure the report with a summary, impact, chronological timeline, root cause, supporting evidence, actions taken, and recommendations. Lead with the conclusion, cite specific metrics and timestamps, and state your confidence level explicitly.

How to distinguish facts from hypotheses during incident investigation?

Facts are directly observed data like pod restart counts, error rates, or memory values at a specific time. Hypotheses are inferences about causes, and each should be labeled with a confidence level and tested against contradicting evidence.

When should I stop investigating an incident?

Stop when you have identified a specific actionable cause, exhausted available diagnostic tools, lack required access, or the user asks you to stop. Do not stop just because you found any error or the first hypothesis seemed plausible.

What is falsification in SRE troubleshooting?

Falsification means actively looking for evidence that would disprove your hypothesis before concluding. For each candidate cause, ask what would contradict it, check for that evidence, and revise or discard the hypothesis when contradicted.

How deep should root cause analysis go for Kubernetes incidents?

Go beyond symptoms like CrashLoopBackOff to actionable depth, such as identifying OOMKilled pods with memory at a specific limit, and ideally the code change responsible. Surface-level findings like 'service is unhealthy' are not useful.