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/root-cause-trace/SKILL.md b/root-cause-trace/SKILL.md
index 74e275d..fad4601 100644
--- a/root-cause-trace/SKILL.md
+++ b/root-cause-trace/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: root-cause-trace
-description: Given an error that manifests deep in the call stack, trace backward through the call chain to find the original trigger, then fix at the source and add defense-in-depth at each intermediate layer. Covers the backward-trace workflow (observe symptom → identify immediate cause → walk up the chain → find origin → fix + layer defenses), when and how to add instrumentation (stack capture before the dangerous operation, not after), and the bisection pattern for identifying which test pollutes shared state. Use when an error appears in the middle or end of an execution path, when a stack trace shows a long chain, when invalid data has unknown origin, or when a failure reproduces inconsistently across runs. Do NOT use for clear local bugs where the fix site is obvious (just fix it), for design-level root-cause analysis of processes/decisions (use five-whys instead), for performance regressions (different class of investigation), or when there's no symptom yet to trace from. Often dispatched from `debug`'s Phase 2 routing when the bug is a code-execution chain; usable directly when the symptom is already clearly a stack-trace walk.
+description: Given an error manifesting deep in the call stack, trace backward through the call chain to the original trigger, fix at the source, and add defense-in-depth at each intermediate layer. Covers the backward-trace workflow (symptom → immediate cause → walk up the chain → origin → fix + layer defenses), when and how to add instrumentation (stack capture before the dangerous operation, not after), and the bisection pattern for finding which test pollutes shared state. Use when an error surfaces mid- or end-execution, a stack trace shows a long chain, invalid data has unknown origin, or a failure reproduces inconsistently across runs. Do NOT use for clear local bugs where the fix is obvious (just fix it), process/decision root-cause analysis (use five-whys), performance regressions (different investigation class), or when there's no concrete symptom yet. Often dispatched from `debug`'s Phase 2 routing for code-execution chains; usable directly when the symptom is already a stack-trace walk.
 ---
 
 # Root-Cause Trace