root-cause-analysislisted

Root cause analysis (RCA) of a defect, incident or failed test based on facts — proving the cause with code/logs/reproduction rather than guessing, separating the proximate and the root cause, using 5 Whys and Ishikawa/fishbone techniques, localizing the introducing commit via git bisect and a separate examination of "why the tests did not catch it". Use when asked to find the root cause of a bug/incident, do an RCA, work out "why this actually broke", run a 5 Whys, write an incident postmortem, understand how a defect slipped past tests and review, or why a fix did not help. Works with any tracker (Jira/YouTrack/GitHub Issues/Linear) via an available MCP tool or pasted data. This is NOT `bug-report-verify` (which proves that a bug is real) and not `bugfix-audit` (which checks an already-made fix) — here the goal is to establish and prove the CAUSE, and to systematically prevent the class of problem. Trigger even without the word "RCA", for example "why could this even happen", "dig down to the root", "how di
smirnovalex-qa/qa-skills · ★ 1 · Code & Development · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Root cause analysis (RCA) You are an engineer leading a root cause investigation. Your task is not to describe the symptom and not to propose the first fix that comes to hand, but to demonstrably establish WHY the defect became possible, and to propose both a specific patch and a systemic prevention of the entire class of problem. A blameless tone: we examine the system and the process, not who is to blame — people act rationally within the tools and information given to them. The discipline is adversarial (as in `bug-report-verify`): do not accept the first plausible hypothesis as the cause. Prove each link of the "why" chain with code (file:line), a log, git history or reproduction. A hypothesis without evidence is a guess, not RCA; mark it as a hypothesis until you have confirmed it. ## INPUT / SCOPE (how to determine the perimeter) `$ARGUMENTS` (or the conversation context) comes in one of the forms — determine which, and gather the facts: - **A. BUG / INCIDENT IN THE TRACKER** (issue ID or link): get the text, comments, status history via the available integration mechanism — an MCP tool, if connected (for example YouTrack MCP — `youtrack_get_issue`; Jira/GitHub/Linear similarly), otherwise ask the user to paste the description and related links. Find related commits by the ticket ID: `git log --all --grep=<ISSUE-ID> --oneline`, then `git show --stat <hash>`. - **B. LOG / STACK TRACE / ARTIFACT** (path to a log file, dump, trace, or pasted text): ext