docs(skills): tighten descriptions under 1000 chars

Trim each long description to <=1000 chars while preserving content (phases, when-to-use, when-not-to, companion references). Frees enough per-session skill-listing budget to quiet the truncation warning on small-context models.

1 files changed, 1 insertions, 1 deletions

diff --git a/five-whys/SKILL.md b/five-whys/SKILL.md
index 3cfacf4..7d7080d 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. Often dispatched from `debug`'s Phase 2 routing when the failure is a process or organizational chain rather than a stack trace.
+description: Drive iterative "why?" questioning from an observed problem to its actual root cause, then fix at the root rather than the symptom. Default depth is five, but the real stop is reaching a cause whose removal prevents every symptom in the chain — may take three whys or eight. Handles branching (multiple contributing causes explored separately), validates by working backward from root to symptom, rejects "human error" as terminal (keep asking why the process allowed it). 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 stack-trace debugging (use root-cause-trace), tactical defect investigation where the fix site is local and obvious, or blame attribution (refuses to terminate at a person). Companion to root-cause-trace — that walks code-execution chains; this walks process/decision chains. Often dispatched from `debug`'s Phase 2 routing.
 ---
 
 # Five Whys