why
installsforks
How to install why?
neolabhq/context-engineering-kit/why
$npx -y skills add NeoLabHQ/context-engineering-kit --skill whyIterative Five Whys root cause analysis drilling from symptoms to fundamentals
SKILL.md
| 1 | # Five Whys Analysis |
| 2 | |
| 3 | Apply Five Whys root cause analysis to investigate issues by iteratively asking "why" to drill from symptoms to root causes. |
| 4 | |
| 5 | ## Description |
| 6 | |
| 7 | Iteratively ask "why" to move from surface symptoms to fundamental causes. Identifies systemic issues rather than quick fixes. |
| 8 | |
| 9 | ## Usage |
| 10 | |
| 11 | `/why [issue_description]` |
| 12 | |
| 13 | ## Variables |
| 14 | |
| 15 | - ISSUE: Problem or symptom to analyze (default: prompt for input) |
| 16 | - DEPTH: Number of "why" iterations (default: 5, adjust as needed) |
| 17 | |
| 18 | ## Steps |
| 19 | |
| 20 | 1. State the problem clearly |
| 21 | 2. Ask "Why did this happen?" and document the answer |
| 22 | 3. For that answer, ask "Why?" again |
| 23 | 4. Continue until reaching root cause (usually 5 iterations) |
| 24 | 5. Validate by working backwards: root cause → symptom |
| 25 | 6. Explore branches if multiple causes emerge |
| 26 | 7. Propose solutions addressing root causes, not symptoms |
| 27 | |
| 28 | ## Examples |
| 29 | |
| 30 | ### Example 1: Production Bug |
| 31 | |
| 32 | ``` |
| 33 | Problem: Users see 500 error on checkout |
| 34 | Why 1: Payment service throws exception |
| 35 | Why 2: Request timeout after 30 seconds |
| 36 | Why 3: Database query takes 45 seconds |
| 37 | Why 4: Missing index on transactions table |
| 38 | Why 5: Index creation wasn't in migration scripts |
| 39 | Root Cause: Migration review process doesn't check query performance |
| 40 | |
| 41 | Solution: Add query performance checks to migration PR template |
| 42 | ``` |
| 43 | |
| 44 | ### Example 2: CI/CD Pipeline Failures |
| 45 | |
| 46 | ``` |
| 47 | Problem: E2E tests fail intermittently |
| 48 | Why 1: Race condition in async test setup |
| 49 | Why 2: Test doesn't wait for database seed completion |
| 50 | Why 3: Seed function doesn't return promise |
| 51 | Why 4: TypeScript didn't catch missing return type |
| 52 | Why 5: strict mode not enabled in test config |
| 53 | Root Cause: Inconsistent TypeScript config between src and tests |
| 54 | |
| 55 | Solution: Unify TypeScript config, enable strict mode everywhere |
| 56 | ``` |
| 57 | |
| 58 | ### Example 3: Multi-Branch Analysis |
| 59 | |
| 60 | ``` |
| 61 | Problem: Feature deployment takes 2 hours |
| 62 | |
| 63 | Branch A (Build): |
| 64 | Why 1: Docker build takes 90 minutes |
| 65 | Why 2: No layer caching |
| 66 | Why 3: Dependencies reinstalled every time |
| 67 | Why 4: Cache invalidated by timestamp in Dockerfile |
| 68 | Root Cause A: Dockerfile uses current timestamp for versioning |
| 69 | |
| 70 | Branch B (Tests): |
| 71 | Why 1: Test suite takes 30 minutes |
| 72 | Why 2: Integration tests run sequentially |
| 73 | Why 3: Test runner config has maxWorkers: 1 |
| 74 | Why 4: Previous developer disabled parallelism due to flaky tests |
| 75 | Root Cause B: Flaky tests masked by disabling parallelism |
| 76 | |
| 77 | Solutions: |
| 78 | A) Remove timestamp from Dockerfile, use git SHA |
| 79 | B) Fix flaky tests, re-enable parallel test execution |
| 80 | ``` |
| 81 | |
| 82 | ## Notes |
| 83 | |
| 84 | - Don't stop at symptoms; keep digging for systemic issues |
| 85 | - Multiple root causes may exist - explore different branches |
| 86 | - Document each "why" for future reference |
| 87 | - Consider both technical and process-related causes |
| 88 | - The magic isn't in exactly 5 whys - stop when you reach the true root cause |
| 89 | - Stop when you hit systemic/process issues, not just technical details |
| 90 | - Multiple root causes are common—explore branches separately |
| 91 | - If "human error" appears, keep digging: why was error possible? |
| 92 | - Document every "why" for future reference |
| 93 | - Root cause usually involves: missing validation, missing docs, unclear process, or missing automation |
| 94 | - Test solutions: implement → verify symptom resolved → monitor for recurrence |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
