القائمة
5 Whys による根本原因分析。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 |
