Menu
Root cause analysis with 5 Whys.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
issue が build に投入できる形かを検分し、verdict (build-ready / needs-plan / needs-fix) と指摘を返す。起票には使わない (/issue)。PR のスクリーニングには使わない (/preview)。
Inspect whether an issue is in shape to hand to build, returning a verdict (build-ready / needs-plan / needs-fix) and the findings. Do NOT use to file an issue (use /issue) or to screen a PR (use /preview).
critic-design による敵対的批判を伴う設計探索。生き残った案を構造化 plan にまとめ、自己点検して呼び出し元に返す。plan の永続先は issue の Plan 節が唯一。計画意図のないコードベース調査には使わない (代わりに /research)。
Design exploration with adversarial critique by critic-design. Assembles the surviving approach into a structured plan, self-checks it, and returns it to the caller. The issue's Plan section is the plan's only persistent home. Do NOT use for codebase investigation without planning intent (use /research instead).
構造化されたタイトルと本文で GitHub Issue を生成する。単独で成立し、前段を要求しない。challenge / research の成果物が会話にあれば本文の根拠に使い、/think の plan 下書きがあれば `## Plan` 節へ移設する。issue 番号を渡すと、起票済みで Plan 節を持たない issue へ plan を転記する。
Generate GitHub Issue with structured title and body. Standalone; requires no upstream stage. When challenge / research artifacts exist in the conversation, they feed the body's evidence; when a /think plan draft exists, it is transferred into the `## Plan` section. Given an issue number, it transfers a plan into a filed issue that has no Plan section.
| name | use-context-root-cause-analysis |
| description | Root cause analysis with 5 Whys. |
| when_to_use | root cause, 5 Whys, なぜなぜ分析, 根本原因, 原因分析, symptom fix, 対症療法 |
| allowed-tools | Read Task Bash(ugrep:*) Bash(bfs:*) |
| context | fork |
| background | false |
| user-invocable | false |
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 such as the /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 |
