Menü
Five Whys分析で問題の根本原因を特定し、本質的な解決策を導出する。問題の原因分析、根本原因の特定、なぜなぜ分析、トラブルシューティング、障害分析、インシデント振り返り、ポストモーテムなど、「なぜこの問題が起きたのか」を深掘りして解決策を考えたい場面で使用する。ユーザーが問題の原因について悩んでいたり、表面的な対処ではなく根本的な解決を求めている場合にも発動する。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
WHEN: the user wants a critical review by the `code-critic` agent. The skill gathers the agent's required Invocation Contract inputs (review target, intent, layer), dispatches the agent via the Agent tool, and drives the **address-then-resubmit** loop until the agent returns an `Approved` verdict or the user explicitly defers what is left.
WHEN: PROACTIVELY when the change introduces or modifies design (new abstraction, new boundary, new module, contract change, security-sensitive interaction, refactor that reshapes responsibility). INPUT: File paths/directory + intent of the change. OUTPUT: Design-level critical issues — contract gaps, architectural misalignment, over-/under-engineered abstractions, security-designed-in failures, systemic problems hidden behind local fixes — with root causes and structural fixes. Implementation defects (logic bugs, races, resource leaks) are out of scope; route those to critic-implementation-review.
WHEN: PROACTIVELY when reviewing code that implements an already-settled design (bug fixes, feature implementation against an agreed shape, optimizations inside an existing module). INPUT: File paths/directory + the design contract being implemented. OUTPUT: Implementation-level critical defects — logic errors, race conditions, resource leaks, concrete security bugs, error-handling gaps, performance problems on real-sized inputs, contract drift between signature and behavior — with concrete fixes. Design-level concerns (abstraction quality, contract shape, architectural fit) are out of scope; route those to critic-design-review.
PRのライフサイクル全体をゲート付きで管理する。PR作成、レビュー対応、マージ、ポストマージまでの一連のワークフローを強制する。PRを作りたい、レビュー対応したい、マージしたい、といった場面で使用する。
OrbStack がホストの Docker runtime として常に利用可能である前提で、Docker Compose 開発環境にアクセスする方法。OrbStack 特有の自動 DNS・自動 port forwarding を活用し、dnsmasq や ports: 公開の手間を省く。Docker Compose 上の Rails/Node 等のサーバーにローカルからアクセスする場面、マルチテナントアプリのサブドメインルーティングを検証する場面で使用する。
WHEN: PROACTIVELY after completing a substantial task (PR merge, feature implementation, bug fix, investigation)—invoke WITHOUT waiting for user request. SKIP for trivial/instant tasks (typo fix, single-line change, quick question answer, config tweak). Also invokable manually via /slack-notify. Sends a completion notification to Slack via Incoming Webhook. Does nothing if CLAUDE_SLACK_NOTIFY_WEBHOOK_URL is not set.
| name | five-whys |
| description | Five Whys分析で問題の根本原因を特定し、本質的な解決策を導出する。問題の原因分析、根本原因の特定、なぜなぜ分析、トラブルシューティング、障害分析、インシデント振り返り、ポストモーテムなど、「なぜこの問題が起きたのか」を深掘りして解決策を考えたい場面で使用する。ユーザーが問題の原因について悩んでいたり、表面的な対処ではなく根本的な解決を求めている場合にも発動する。 |
| user-invocable | true |
問題の表面的な症状ではなく、根本原因を特定し、本質的な解決策を導出する。
$ARGUMENTS で問題の記述を受け取る。引数がない場合は、直前の会話コンテキストから問題を抽出する。
Five Whys分析は事実の連鎖でなければならない。推測や仮説で因果関係を埋めた分析は無価値であり、誤った結論と的外れな対策を生む。
各「なぜ？」の回答は、以下のいずれかの事実に裏付けられていなければならない:
事実が不足している場合、分析を推測で進めてはならない。代わりに:
問題を1文で明確に定義する。具体的・観察可能な事象として記述する。
ユーザーの記述が曖昧な場合は、定義を明確化するための質問をする。
分析を始める前に、利用可能な事実を整理する。
収集した事実が分析を進めるのに十分かどうかを判断してから、Step 3に進む。
事実に基づいて「なぜ？」を繰り返し、因果関係の連鎖を掘り下げる。
実行ルール:
Five Whysの連鎖から根本原因を特定する。判定基準:
3つすべてを満たすものが根本原因。事実の連鎖で到達できなかった場合は、根本原因を「未確定」とし、確定に必要な追加調査を提示する。
根本原因が特定できた場合のみ、解決策を検討する。3層で提案する:
| 層 | 説明 | 例 |
|---|---|---|
| 即時対処 | 今起きている症状を止める応急措置 | ホットフィックス、手動リカバリ |
| 直接対策 | 根本原因を直接解消する施策 | 設計変更、プロセス改善 |
| 再発防止 | 同種の問題が将来発生しない仕組み | 自動検知、ガードレール、教育 |
解決策の評価基準:
## 問題定義
[1文で定義した問題]
## 確認済みの事実
- [事実1: 出典]
- [事実2: 出典]
- ...
## Five Whys 分析
| # | なぜ？ | 回答 | 裏付ける事実 |
|---|--------|------|-------------|
| 1 | なぜ[問題]が起きたのか？ | ... | [具体的な事実への参照] |
| 2 | なぜ[Why1の回答]なのか？ | ... | [具体的な事実への参照] |
| ... | ... | ... | ... |
> **分岐**: [因果関係が分岐した箇所と、選択しなかった経路の簡潔な記録]
> （分岐がない場合は省略）
## 根本原因
[特定した根本原因]
- 除去可能性: [評価]
- 制御可能性: [評価]
- 構造性: [評価]
## 解決策
### 即時対処
- [施策]: [効果 / 実現性 / 副作用の簡潔な評価]
### 直接対策
- [施策]: [効果 / 実現性 / 副作用の簡潔な評価]
### 再発防止
- [施策]: [効果 / 実現性 / 副作用の簡潔な評価]
## 推奨アクション
[最も優先すべきアクションを1-3個、具体的に記述]
## 問題定義
[1文で定義した問題]
## 確認済みの事実
- [事実1: 出典]
- ...
## Five Whys 分析（途中）
| # | なぜ？ | 回答 | 裏付ける事実 |
|---|--------|------|-------------|
| 1 | ... | ... | [事実] |
| 2 | ... | ... | [事実] |
| 3 | ← ここで事実が不足 | — | — |
## 分析を進めるために必要な情報
以下の情報が得られれば、分析を継続できる:
1. [必要な情報1]: [なぜこの情報が必要か]
2. [必要な情報2]: [なぜこの情報が必要か]
### 情報の収集方法（提案）
- [情報1の収集方法: ログの確認先、確認すべきメトリクス、聞くべき人など]
- [情報2の収集方法]