From ship
Diagnoses root causes of failures using the 5 Whys technique, distinguishing isolated, recurring, or systematic issues.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ship:use-context-root-cause-analysisWhen to use
root cause, 5 Whys, なぜなぜ分析, 根本原因, 原因分析, symptom fix, 対症療法
This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Fix the root cause, not the symptom. Symptom fixes add complexity; root-cause fixes prevent recurrence.
Fix the root cause, not the symptom. Symptom fixes add complexity; root-cause fixes prevent recurrence.
Ask "why" five times, descending through abstraction levels.
| Step | Level |
|---|---|
| 1 | Observable fact |
| 2 | Implementation detail |
| 3 | Design decision |
| 4 | Architectural constraint |
| 5 | Root cause |
| Tip | Description |
|---|---|
| Stay factual | Evidence, not assumptions |
| Don't stop early | First "why" is rarely root cause |
| Don't go deep | Stop when actionable |
| Validate | "Because [5], therefore [4]..." |
| Verify fix | "Will this prevent the problem?" |
| Watch complexity signals | When intermittent / multiple independent changes overlap / behavior unexplained, enumerate ≥3 cause-layer candidates before converging |
| Field | Description |
|---|---|
| Symptom | User-facing failure |
| Root cause | Why the failure occurred (5 Whys result) |
| Pattern | Isolated / Recurring / Systematic |
Consumers (e.g., /fix Non-obvious flow) branch on the Pattern field to decide whether to apply defense-in-depth or escalate.
| Value | Meaning |
|---|---|
| Isolated | Single location, no recurrence path |
| Recurring | Similar code exists nearby, recurrence possible |
| Systematic | Design-rooted, architecture-level recurrence risk |
| Topic | File |
|---|---|
| Worked examples | ${CLAUDE_SKILL_DIR}/references/five-whys.md |
| Symptom → Root Cause | ${CLAUDE_SKILL_DIR}/references/symptom-patterns.md |
npx claudepluginhub thkt/dotclaude --plugin shipIterates 'why?' to uncover systemic root causes rather than surface symptoms. Useful for incident post-mortems, debugging sessions, and process improvement.
Investigates root causes of defects or incidents by iteratively asking 'why' to trace failures from symptoms to systemic causes. Useful for postmortems and recurring failures.
Five Whys, fishbone diagrams, identifying systemic causes not just symptoms.