
Bmad Os Root Cause Analysis
- 1 installs
- 8 repo stars
- Updated June 28, 2026
- bmad-code-org/bmad-utility-skills
bmad-os-root-cause-analysis is a skill that performs root cause analysis on a bug fix and produces a structured RCA report.
About
This skill performs root cause analysis on a bug fix and produces a structured RCA report. A developer runs it on a commit, PR, issue, or description of a fix to find what caused the defect, when it was introduced, and which guardrails failed. It reads the fix diff and discussion, uses git blame and 5 Whys, and writes a report with a detection-latency timeline and corrective actions.
- Produces a structured RCA report from a commit, PR, issue, or description
- Uses git blame and 5 Whys to identify who introduced the defect and when
- Evaluates why each CI, linter, and test guardrail missed the bug
Bmad Os Root Cause Analysis by the numbers
- 1 all-time installs (skills.sh)
- Ranked #489 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 1, 2026 (Skillselion catalog sync)
bmad-os-root-cause-analysis capabilities & compatibility
- Capabilities
- root cause analysis · bug analysis · postmortem
- Works with
- github
- Use cases
- debugging · code review
What bmad-os-root-cause-analysis says it does
Analyze a bug-fix commit or PR and produce a structured Root Cause Analysis report.
Apply 5 Whys. Classify the root cause. Identify contributing factors.
npx skills add https://github.com/bmad-code-org/bmad-utility-skills --skill bmad-os-root-cause-analysisAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 8 |
| Last updated | June 28, 2026 |
| Repository | bmad-code-org/bmad-utility-skills ↗ |
What it does
Perform root cause analysis on a bug fix and produce a structured RCA report with a 5 Whys analysis and failed-guardrail review.
Who is it for?
Teams that want a factual RCA report attributing a defect and reviewing why guardrails missed it.
Skip if: Blameless-postmortem cultures, since the skill deliberately names the individual who introduced the defect.
When should I use this skill?
A user says to run RCA on a commit or PR, requests root cause analysis, or asks what caused a bug.
What you get
A structured RCA report with root cause category, detection latency, and corrective and preventive actions.
- structured RCA report
By the numbers
- applies a 5 Whys analysis
- writes reports to _bmad-output/rca-reports/
Files
Bug-Fix Root Cause Analysis
Analyze a bug-fix commit or PR and produce a structured Root Cause Analysis report.
Principles
- Direct attribution. This report names the individual who introduced the defect. Industry convention advocates blameless postmortems. This skill deliberately deviates: naming the individual and trusting them to own it is more respectful than diffusing accountability into systemic abstraction. Direct, factual, not accusatory. If authorship can't be determined confidently, say so.
- Pyramid communication. The executive summary must convey the full picture. A reader who stops after the first paragraph gets the gist. Everything else is supporting evidence.
Preflight
Verify gh auth status and that you're in a git repository. Stop with a clear message if either fails.
Execution
1. Identify the fix. Accept whatever the user provides — commit SHA, PR, issue, description. Resolve to the specific fix commit/PR using gh and git. If ambiguous, ask. Confirm the change is actually a bug fix before proceeding. 2. Gather evidence. Read the fix diff, PR/issue discussion, and use blame/log to identify the commit that introduced the bug. Collect timeline data. 3. Analyze. Apply 5 Whys. Classify the root cause. Identify contributing factors. 4. Evaluate guardrails. Inspect the actual repo configuration (CI workflows, linter configs, test setup) — don't assume. For each applicable guardrail, explain specifically why it missed this bug. 5. Write the report to _bmad-output/rca-reports/rca-{YYYY-MM-DD}-{slug}.md. Present the executive summary in chat.
Report Structure
# Root Cause Analysis: {Bug Title}
**Date:** {today}
**Fix:** {PR link or commit SHA}
**Severity:** {Critical | High | Medium | Low}
**Root Cause Category:** {Requirements | Design | Code Logic | Test Gap | Process | Environment/Config}
## Executive Summary
{One paragraph. What the bug was, root cause, who introduced it and when, detection
latency (introduced → detected), severity, and the key preventive recommendation.}
## What Was the Problem?
## When Did It Happen?
| Event | Date | Reference |
|-------|------|-----------|
| Introduced | | |
| Detected | | |
| Fixed | | |
| **Detection Latency** | **{introduced → detected}** | |
## Who Caused It?
{Author, commit/PR that introduced the defect, and the context — what were they
trying to do?}
## How Did It Happen?
## Why Did It Happen?
{5 Whys analysis. Root cause category. Contributing factors.}
## Failed Guardrails Analysis
| Guardrail | In Place? | Why It Failed |
|-----------|-----------|---------------|
| | | |
**Most Critical Failure:** {Which one mattered most and why.}
## Resolution
## Corrective & Preventive Actions
| # | Action | Type | Priority |
|---|--------|------|----------|
| | | {Prevent/Detect/Mitigate} | |Related skills
FAQ
What inputs does it accept?
A commit SHA, PR number, issue, or a description of the fix.
Is it blameless?
No. It deliberately names the individual who introduced the defect, factually and not accusatory.