why

SKILL.md

Five Whys Analysis

Apply Five Whys root cause analysis to investigate issues by iteratively asking "why" to drill from symptoms to root causes.

Description

Iteratively ask "why" to move from surface symptoms to fundamental causes. Identifies systemic issues rather than quick fixes.

Usage

/why [issue_description]

Variables

ISSUE: Problem or symptom to analyze (default: prompt for input)

DEPTH: Number of "why" iterations (default: 5, adjust as needed)

Steps

State the problem clearly

Ask "Why did this happen?" and document the answer

For that answer, ask "Why?" again

Continue until reaching root cause (usually 5 iterations)

Validate by working backwards: root cause → symptom

Explore branches if multiple causes emerge

Propose solutions addressing root causes, not symptoms

Examples

Example 1: Production Bug

Problem: Users see 500 error on checkout
Why 1: Payment service throws exception
Why 2: Request timeout after 30 seconds
Why 3: Database query takes 45 seconds
Why 4: Missing index on transactions table
Why 5: Index creation wasn't in migration scripts
Root Cause: Migration review process doesn't check query performance

Solution: Add query performance checks to migration PR template

Example 2: CI/CD Pipeline Failures

Problem: E2E tests fail intermittently
Why 1: Race condition in async test setup
Why 2: Test doesn't wait for database seed completion
Why 3: Seed function doesn't return promise
Why 4: TypeScript didn't catch missing return type
Why 5: strict mode not enabled in test config
Root Cause: Inconsistent TypeScript config between src and tests

Solution: Unify TypeScript config, enable strict mode everywhere

Example 3: Multi-Branch Analysis

Problem: Feature deployment takes 2 hours

Branch A (Build):
Why 1: Docker build takes 90 minutes
Why 2: No layer caching
Why 3: Dependencies reinstalled every time
Why 4: Cache invalidated by timestamp in Dockerfile
Root Cause A: Dockerfile uses current timestamp for versioning

Branch B (Tests):
Why 1: Test suite takes 30 minutes
Why 2: Integration tests run sequentially
Why 3: Test runner config has maxWorkers: 1
Why 4: Previous developer disabled parallelism due to flaky tests
Root Cause B: Flaky tests masked by disabling parallelism

Solutions: 
A) Remove timestamp from Dockerfile, use git SHA
B) Fix flaky tests, re-enable parallel test execution

Notes

Don't stop at symptoms; keep digging for systemic issues

Multiple root causes may exist - explore different branches

Document each "why" for future reference

Consider both technical and process-related causes

The magic isn't in exactly 5 whys - stop when you reach the true root cause

Stop when you hit systemic/process issues, not just technical details

Multiple root causes are common—explore branches separately

If "human error" appears, keep digging: why was error possible?

Document every "why" for future reference

Root cause usually involves: missing validation, missing docs, unclear process, or missing automation

Test solutions: implement → verify symptom resolved → monitor for recurrence