Five Whys — Root Cause Analysis

The Rule

DO NOT FIX THE SYMPTOM. FIND THE CAUSE.

A fix that doesn't address the root cause is temporary. The cause returns.

Protocol

Step 1 — Define the problem precisely

One concrete sentence. Not vague.

Step 2 — Five Whys cascade

For each answer, ask: "Why does that happen?"

Don't stop until you reach something you control — a decision, a process, a line of code, a missing configuration.

Problem: Users see another user's data
  Why 1: Cache returns the wrong entry
  Why 2: Cache key does not include user_id
  Why 3: Developer assumed the endpoint was public
  Why 4: No isolation test existed for this endpoint
  Why 5: Code review had no data isolation checklist
  → Root cause: review process missing a security checklist

Step 3 — Validate in reverse

Read the chain bottom-up: "No review checklist → cache key missing user_id → data leak." If the chain holds, the root cause is valid.

Step 4 — Fix at the root, not the symptom

Fix at the deepest level that is practical to change.

If you can only fix an intermediate level, document the root cause as tracked technical debt with a concrete TODO.

Branching

A root cause can have multiple branches — explore all before choosing where to fix.

Problem: Deploy fails in prod but not in staging
  Branch A: different configuration (env vars, secrets)
  Branch B: prod data has different volume or format
  Branch C: network dependencies only reachable in prod

Test each branch independently. Do not assume.

When to Stop

Stop before the 5th why if you reach a clear, actionable root cause. Stop after the 5th if the chain hasn't converged — there may be multiple independent root causes.

Output

Document the analysis:

**Problem:** [concrete one-liner]
**Root cause:** [deepest level found]
**Fix:** [concrete action with file/component]
**Temporary fix (if needed):** [what you apply now while the real fix is in progress]
**Technical debt:** [what remains unresolved and why]

Integration with A Team

• Run this skill before launching the systematic-debugging agent — Five Whys defines the investigation scope
• After finding the root cause, use the tdd-guide agent to write the test that would have caught it
• If the root cause implies a process change, document the analysis in DAILY.md