diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-06 05:23:01 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-06 05:23:01 -0500 |
| commit | 7f51ed751ce8bf1dad23cfd9534d1238f538671e (patch) | |
| tree | 2b3e21eccea8b67eddcd7c6318ee262216328dc6 /five-whys | |
| parent | 40dda3a48fbfbc14dd76c3e21d289a1b0fa813a8 (diff) | |
| download | rulesets-7f51ed751ce8bf1dad23cfd9534d1238f538671e.tar.gz rulesets-7f51ed751ce8bf1dad23cfd9534d1238f538671e.zip | |
refactor(debug): make debug a triage router, align specialist cross-refs
I sharpened the debug skill so it stops duplicating root-cause-trace and five-whys. Phase 1 captures evidence and stops there. Phase 2 routes to the right specialist instead of asking why three times inline. Phases 3 and 4 keep the verify-and-fix discipline. I also updated the companion lines in root-cause-trace and five-whys so all three descriptions stay in sync.
Diffstat (limited to 'five-whys')
| -rw-r--r-- | five-whys/SKILL.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/five-whys/SKILL.md b/five-whys/SKILL.md index 3549222..3cfacf4 100644 --- a/five-whys/SKILL.md +++ b/five-whys/SKILL.md @@ -1,6 +1,6 @@ --- name: five-whys -description: Drive iterative "why?" questioning from an observed problem to its actual root cause, then propose fixes that target the root rather than the symptom. Default depth is five, but the real stop condition is reaching a cause that, if eliminated, would prevent every observed symptom in the chain — that may take three whys or eight. Handles branching (multiple contributing causes, each explored separately), validates the chain by working backward from root to symptom, and rejects "human error" as a terminal answer (keep asking why the process allowed that error). Use for process, decision, and organizational failures — missed code reviews, recurring incidents, slow deploys, flaky releases, "we've fixed this three times already" problems. Do NOT use for debugging a stack trace (use root-cause-trace, which walks the call chain), for tactical defect investigation where the fix site is local and obvious, or for blame attribution (the skill refuses to terminate at a person). Companion to root-cause-trace — that's for code execution; this is for process/decision root-causes. +description: Drive iterative "why?" questioning from an observed problem to its actual root cause, then propose fixes that target the root rather than the symptom. Default depth is five, but the real stop condition is reaching a cause that, if eliminated, would prevent every observed symptom in the chain — that may take three whys or eight. Handles branching (multiple contributing causes, each explored separately), validates the chain by working backward from root to symptom, and rejects "human error" as a terminal answer (keep asking why the process allowed that error). Use for process, decision, and organizational failures — missed code reviews, recurring incidents, slow deploys, flaky releases, "we've fixed this three times already" problems. Do NOT use for debugging a stack trace (use root-cause-trace, which walks the call chain), for tactical defect investigation where the fix site is local and obvious, or for blame attribution (the skill refuses to terminate at a person). Companion to root-cause-trace — that's for code execution; this is for process/decision root-causes. Often dispatched from `debug`'s Phase 2 routing when the failure is a process or organizational chain rather than a stack trace. --- # Five Whys |