rca

Draft a blameless root cause analysis from incident evidence into docs/rca/<slug>.md.

5|Updated Apr 29, 2026
One-click install
npx skills add https://github.com/friedbotstudio/baseline --skill rca-friedbotstudio
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rca
Source: https://github.com/friedbotstudio/baseline/tree/main/.claude/skills/rca
Command: npx skills add https://github.com/friedbotstudio/baseline --skill rca-friedbotstudio

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you turn incidents, outages, and recurring test failures into a clear blameless root cause analysis that explains what happened, why it happened, and what should change next.

Core Features & Use Cases

  • Evidence-based narrative: Builds a timeline from logs, alerts, deploys, chats, and other incident evidence instead of relying on memory.
  • Impact and resolution tracking: Captures quantified impact, the resolution taken, and what went well so the postmortem is complete and useful.
  • Actionable follow-up: Produces action items with named owners and due dates, making it easy to route a bugfix or process improvement afterward.
  • Use case: Use it after a production outage, a recurring flaky failure, or a failed verification run that needs a formal incident review.

Quick Start

Ask the RCA skill to draft a postmortem from your incident evidence and it will write a completed analysis to docs/rca/<slug>.md.

Frequently Asked Questions about rca

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

FAQPage Schema
How do I write a blameless postmortem after a production outage?

To write a blameless postmortem after a production outage, you need an evidence-based timeline, quantified impact, a single-sentence root cause, linked references, and assigned action items with owners and due dates.

What is a blameless root cause analysis and when do I need one?

A blameless root cause analysis is a formal incident review document that explains why an outage or repeated test failure occurred without assigning personal blame, needed when your team requires a standalone artifact before a bugfix intake.

How do I create an incident review from logs and alerts?

You create an incident review from logs and alerts by building an evidence-based narrative timeline, capturing the resolution taken, and generating action items with named owners and due dates written to a markdown file.

What is the best way to document recurring test failures for a bugfix intake?

The best way to document recurring test failures for a bugfix intake is to draft a root cause analysis that captures the quantified impact, resolution taken, and action items with assigned owners and due dates.

Can I use a root cause analysis for recurring flaky test failures?

Yes, you can use a root cause analysis for recurring flaky test failures, as the process captures the evidence-based timeline, quantified impact, and action items needed to formally review the incident and route a bugfix.

What should a complete incident review document include?

A complete incident review document should include an evidence-based timeline, quantified impact, a single-sentence root cause, linked references, what went well, and action items with assigned owners and due dates.