Menü
Root cause analysis with 5 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
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 |
