use-context-root-cause-analysis
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.
Menu
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 | 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 |
症状ではなく根本原因を修正する。対症療法は複雑性を増やし、根本原因の修正は再発を防ぐ。
「なぜ」を 5 回問う。抽象度を下げながら掘り下げる。
| ステップ | 階層 |
|---|---|
| 1 | 観察可能な事実 |
| 2 | 実装の詳細 |
| 3 | 設計判断 |
| 4 | アーキテクチャ制約 |
| 5 | 根本原因 |
| ヒント | 説明 |
|---|---|
| 事実に基づく | 仮定ではなく根拠 |
| 早く止めない | 最初の「なぜ」が根本原因であることは少ない |
| 深く行きすぎない | アクション可能になったら止める |
| 検証 | 「[5] だから [4]、よって ...」で確かめる |
| 修正を検証 | 「これで問題が防げるか」 |
| 複雑性シグナルに注意 | 間欠的 / 複数の独立した変更が重なる / 挙動を説明できない場合は、収束する前に原因階層の候補を 3 つ以上列挙する |
| フィールド | 説明 |
|---|---|
| Symptom | ユーザーから見た失敗 |
| Root cause | 5 Whys で辿り着いた失敗の原因 |
| Pattern | Isolated / Recurring / Systematic |
/fix の Non-obvious flow のような利用側は Pattern フィールドで分岐し、defense-in-depth を適用するか escalate するかを判断する。
| 値 | 意味 |
|---|---|
| Isolated | 単一箇所、再発経路なし |
| Recurring | 近くに類似コードあり、再発の可能性 |
| Systematic | 設計に根ざす、アーキテクチャレベルの再発リスク |
| トピック | ファイル |
|---|---|
| 実例 | ${CLAUDE_SKILL_DIR}/references/five-whys.md |
| Symptom → Root Cause | ${CLAUDE_SKILL_DIR}/references/symptom-patterns.md |