rca

Organize incident facts into an evidence-based root cause analysis document.

1|Updated Jul 17, 2026
One-click install
npx skills add https://github.com/Arafly/sre-playbooks --skill rca-arafly
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rca
Source: https://github.com/Arafly/sre-playbooks/tree/main/rca
Command: npx skills add https://github.com/Arafly/sre-playbooks --skill rca-arafly

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps teams turn a restored incident into a rigorous, evidence-based root cause analysis instead of a blame-focused or speculative postmortem. It is designed to reduce narrative bias, separate facts from inference, and produce a document that can stand up to technical and leadership review.

Core Features & Use Cases

  • Evidence-driven RCA creation: Builds an incident timeline from logs, metrics, traces, deployment history, chat transcripts, and other artifacts.
  • Causal analysis and system improvement: Identifies contributing factors, systemic root causes, and corrective actions with owners and success criteria.
  • Review and validation workflow: Uses fresh-reviewer checks to challenge assumptions, surface gaps, and confirm operational readiness before publication.
  • Use Case: A post-incident team can use this Skill to convert a chaotic outage report into a defensible RCA package with clear facts, causes, actions, and review results.

Quick Start

Use the rca skill to analyze this incident timeline and supporting evidence, then draft a defensible root cause analysis with facts, causal chain, and corrective actions.

Frequently Asked Questions about rca

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

FAQPage Schema
How do I write an evidence-based root cause analysis for a postmortem?

To write an evidence-based root cause analysis, build an incident timeline from logs and metrics, separate verified facts from inference, and challenge competing explanations to produce a defensible postmortem document.

What is the best way to structure an incident review to reduce narrative bias?

The best way to structure an incident review is to enforce a workflow that builds an evidence inventory, develops a causal chain, and uses fresh-reviewer checks to challenge assumptions before publication.

How do I distinguish verified facts from inference during a post-incident review?

You distinguish verified facts from inference by organizing artifacts like chat transcripts and deployment history into a structured evidence inventory before developing causal chains.

Can I use a structured workflow to validate operational readiness before publishing an RCA?

Yes, you can validate operational readiness before publishing an RCA by applying independent review checks to challenge assumptions, surface gaps, and confirm corrective actions meet success criteria.

What should be included in an incident timeline for a defensible root cause analysis?

An incident timeline for a defensible root cause analysis should include facts extracted from logs, metrics, traces, deployment history, and chat transcripts organized chronologically.

How do I identify contributing factors and systemic root causes after an outage?

To identify contributing factors and systemic root causes, analyze the evidence timeline to map causality, determine impact, and define corrective actions with assigned owners and success criteria.