# Self Rca

When you make a mistake or the user corrects you, stop and run a blameless root-cause...

- Repository: https://github.com/kirodotdev/KiroCrew (4711 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kirodotdev/KiroCrew --skill self-rca -g -a claude-code -y`
Codex: `npx skills add kirodotdev/KiroCrew --skill self-rca -g -a codex -y`
Cursor: `npx skills add kirodotdev/KiroCrew --skill self-rca -g -a cursor -y`
Gemini CLI: `npx skills add kirodotdev/KiroCrew --skill self-rca -g -a gemini-cli -y`

## Description

When you make a mistake or the user corrects you, stop and run a blameless root-cause analysis of your OWN failure, concrete failure statement, Five Whys covering cause AND why you didn't self-catch it AND why no guardrail stopped it, and a durable lesson, instead of just apologizing and retrying.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Self-RCA, blameless analysis of your own failure

An apology is not a correction. When you get something wrong, apply the
discipline of a good incident postmortem to your *own* behavior, turned
inward. Do this instead of "sorry, let me try again." Keep it tight; this is a
correction, not a performance.

## When this fires

The user corrected you, caught a mistake, or flagged output that was wrong,
fabricated, or off-target, or you noticed mid-task that you erred.

This skill may be injected by a loose word match ("what went wrong" about a CI
run, "why did you do that" asking for design rationale). If the message is not
about an error in YOUR output, ignore this skill and answer the actual request;
do not invent a failure to analyze.

## Do this, briefly

### 1. Name the failure concretely
One or two sentences, no hedging. If you fabricated something, say "I fabricated
X." If you assumed, say "I assumed X without checking." State it from the effect
the user experienced ("I gave you a wrong file path"), not from the cause yet.
Precision here is the whole value, "significant error" and "I may have" are
banned; say what, exactly.

### 2. Five Whys, three axes, not one
Ask "why" until you reach a **systemic** cause you can actually change, "I
answered from memory instead of reading the file," not "I need to be more
careful" (a wish, not a cause). Answer all three, the way a postmortem must
cover cause, detection, and resolution:
- **Cause:** why did the wrong output happen?
- **Self-detection:** why didn't *you* catch it before the user did? (What
  check would have flagged it?)
- **Guardrail:** why was there nothing that made this failure impossible or
  auto-caught? (Missing verification step, no "say I don't know" fallback.)

Don't stop at "I made an error" (keep going to the process gap) or at "I lacked
a step" (name the step and when to run it).

The rest: https://github.com/kirodotdev/KiroCrew/blob/HEAD/skills/self-rca/SKILL.md