Why
Run a structured Five Whys session with your agent to move from a visible failure to the systemic root cause and a fix that prevents recurrence.
Overview
why is a journey-wide agent skill that runs Five Whys root cause analysis—usable whenever a solo builder needs to drill from symptoms to systemic causes before committing to a fix.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill whyWhat is this skill?
- Seven-step ritual: state problem, iterate why (default depth 5), validate backward, branch causes, propose root-level so
- Configurable DEPTH when five iterations are not enough
- Worked examples for production checkout errors and CI/CD E2E failures
- Explicit validation pass from root cause back to observable symptom
- Branches when multiple parallel causes appear
- Default 5 why iterations (DEPTH configurable)
- 7 documented analysis steps including backward validation and branching
Adoption & trust: 533 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You keep fixing the same symptom—timeouts, 500s, or flaky CI—without knowing which process or design gap actually causes it.
Who is it for?
Recurring production or pipeline failures where quick fixes failed and you want a written RCA your agent can extend into tickets or PR checklist changes.
Skip if: Single-line typos or one-off stack traces where a direct debug pass is enough; skip when you already have an approved root-cause write-up.
When should I use this skill?
You need iterative Five Whys analysis from a stated issue or symptom, via `/why [issue_description]` or prompted ISSUE.
What do I get? / Deliverables
You get a documented why-chain, a validated root cause, and solution ideas aimed at the fundamental fix rather than another surface patch.
- Written why-chain from symptom to root cause
- Backward validation narrative
- Root-cause-oriented solution proposals
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Trace a recurring payment timeout from HTTP 500 through slow queries to a missing index and a weak migration review process.
When E2E tests fail intermittently, drill past the failing assertion to infrastructure or data setup gaps.
After a third-party webhook fails, ask why through retries, idempotency, and config until you fix the contract—not the log line.
When a demo feature “almost works,” uncover whether the blocker is scope, missing env, or an unvalidated assumption.
Turn repeated support themes into a why-chain that points to product or docs fixes instead of more macros.
How it compares
Use as a structured RCA ritual instead of ad-hoc “guess and patch” chat debugging.
Common Questions / FAQ
Who is why for?
Solo and indie builders using Claude Code, Cursor, or similar agents who own incidents end-to-end and need repeatable root-cause thinking without a formal SRE team.
When should I use why?
When checkout errors, slow queries, missing migrations, or E2E failures keep coming back; during ship hardening before launch; when operating production you need process fixes; or in validate when a prototype “works” but the same blocker keeps appearing for the same underlying re
Is why safe to install?
It is procedural analysis only—no shell or network by default. Review the Security Audits panel on this Prism page before enabling any bundled repo scripts.
SKILL.md
READMESKILL.md - Why
# 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 1. State the problem clearly 2. Ask "Why did this happen?" and document the answer 3. For that answer, ask "Why?" again 4. Continue until reaching root cause (usually 5 iterations) 5. Validate by working backwards: root cause → symptom 6. Explore branches if multiple causes emerge 7. 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