SKILL.md
9.3 KB查看排版效果| 1 | --- |
| 2 | name: systematic-debugging |
| 3 | description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes |
| 4 | --- |
| 5 | |
| 6 | # Systematic Debugging |
| 7 | |
| 8 | ## Overview |
| 9 | |
| 10 | **Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure. |
| 11 | |
| 12 | **Violating the letter of this process is violating the spirit of debugging.** |
| 13 | |
| 14 | ## The Iron Law |
| 15 | |
| 16 | ``` |
| 17 | NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST |
| 18 | ``` |
| 19 | |
| 20 | If you haven't completed Phase 1, you cannot propose fixes. |
| 21 | |
| 22 | ## When to Use |
| 23 | |
| 24 | Use for ANY technical issue: |
| 25 | - Test failures |
| 26 | - Bugs in production |
| 27 | - Unexpected behavior |
| 28 | - Performance problems |
| 29 | - Build failures |
| 30 | - Integration issues |
| 31 | |
| 32 | **Use this ESPECIALLY when:** |
| 33 | - Under time pressure (emergencies make guessing tempting) |
| 34 | - "Just one quick fix" seems obvious |
| 35 | - You've already tried multiple fixes |
| 36 | - Previous fix didn't work |
| 37 | - You don't fully understand the issue |
| 38 | |
| 39 | **Don't skip when:** |
| 40 | - Issue seems simple (simple bugs have root causes too) |
| 41 | - You're in a hurry (rushing guarantees rework) |
| 42 | - Manager wants it fixed NOW (systematic is faster than thrashing) |
| 43 | |
| 44 | ## The Four Phases |
| 45 | |
| 46 | You MUST complete each phase before proceeding to the next. |
| 47 | |
| 48 | ### Phase 1: Root Cause Investigation |
| 49 | |
| 50 | **BEFORE attempting ANY fix:** |
| 51 | |
| 52 | 1. **Read Error Messages Carefully** |
| 53 | - Don't skip past errors or warnings |
| 54 | - They often contain the exact solution |
| 55 | - Read stack traces completely |
| 56 | - Note line numbers, file paths, error codes |
| 57 | |
| 58 | 2. **Reproduce Consistently** |
| 59 | - Can you trigger it reliably? |
| 60 | - What are the exact steps? |
| 61 | - Does it happen every time? |
| 62 | - If not reproducible → gather more data, don't guess |
| 63 | |
| 64 | 3. **Check Recent Changes** |
| 65 | - What changed that could cause this? |
| 66 | - Git diff, recent commits |
| 67 | - New dependencies, config changes |
| 68 | - Environmental differences |
| 69 | |
| 70 | 4. **Gather Evidence in Multi-Component Systems** |
| 71 | |
| 72 | **WHEN system has multiple components (CI → build → signing, API → service → database):** |
| 73 | |
| 74 | **BEFORE proposing fixes, add diagnostic instrumentation:** |
| 75 | ``` |
| 76 | For EACH component boundary: |
| 77 | - Log what data enters component |
| 78 | - Log what data exits component |
| 79 | - Verify environment/config propagation |
| 80 | - Check state at each layer |
| 81 | |
| 82 | Run once to gather evidence showing WHERE it breaks |
| 83 | THEN analyze evidence to identify failing component |
| 84 | THEN investigate that specific component |
| 85 | ``` |
| 86 | |
| 87 | **Example (multi-layer system):** |
| 88 | ```bash |
| 89 | # Layer 1: Workflow |
| 90 | echo "=== Secrets available in workflow: ===" |
| 91 | echo "IDENTITY: $([ -n "${IDENTITY:-}" ] && echo SET || echo UNSET)" |
| 92 | |
| 93 | # Layer 2: Build script |
| 94 | echo "=== Env vars in build script: ===" |
| 95 | printenv IDENTITY >/dev/null 2>&1 && echo "IDENTITY in environment" || echo "IDENTITY not in environment" |
| 96 | |
| 97 | # Layer 3: Signing script |
| 98 | echo "=== Keychain state: ===" |
| 99 | security list-keychains |
| 100 | security find-identity -v |
| 101 | |
| 102 | # Layer 4: Actual signing |
| 103 | codesign --sign "$IDENTITY" --verbose=4 "$APP" |
| 104 | ``` |
| 105 | |
| 106 | **This reveals:** Which layer fails (secrets → workflow ✓, workflow → build ✗) |
| 107 | |
| 108 | 5. **Trace Data Flow** |
| 109 | |
| 110 | **WHEN error is deep in call stack:** |
| 111 | |
| 112 | See `root-cause-tracing.md` in this directory for the complete backward tracing technique. |
| 113 | |
| 114 | **Quick version:** |
| 115 | - Where does bad value originate? |
| 116 | - What called this with bad value? |
| 117 | - Keep tracing up until you find the source |
| 118 | - Fix at source, not at symptom |
| 119 | |
| 120 | ### Phase 2: Pattern Analysis |
| 121 | |
| 122 | **Find the pattern before fixing:** |
| 123 | |
| 124 | 1. **Find Working Examples** |
| 125 | - Locate similar working code in same codebase |
| 126 | - What works that's similar to what's broken? |
| 127 | |
| 128 | 2. **Compare Against References** |
| 129 | - If implementing pattern, read reference implementation COMPLETELY |
| 130 | - Don't skim - read every line |
| 131 | - Understand the pattern fully before applying |
| 132 | |
| 133 | 3. **Identify Differences** |
| 134 | - What's different between working and broken? |
| 135 | - List every difference, however small |
| 136 | - Don't assume "that can't matter" |
| 137 | |
| 138 | 4. **Understand Dependencies** |
| 139 | - What other components does this need? |
| 140 | - What settings, config, environment? |
| 141 | - What assumptions does it make? |
| 142 | |
| 143 | ### Phase 3: Hypothesis and Testing |
| 144 | |
| 145 | **Scientific method:** |
| 146 | |
| 147 | 1. **Form Single Hypothesis** |
| 148 | - State clearly: "I think X is the root cause because Y" |
| 149 | - Write it down |
| 150 | - Be specific, not vague |
| 151 | |
| 152 | 2. **Test Minimally** |
| 153 | - Make the SMALLEST possible change to test hypothesis |
| 154 | - One variable at a time |
| 155 | - Don't fix multiple things at once |
| 156 | |
| 157 | 3. **Verify Before Continuing** |
| 158 | - Did it work? Yes → Phase 4 |
| 159 | - Didn't work? Form NEW hypothesis |
| 160 | - DON'T add more fixes on top |
| 161 | |
| 162 | 4. **When You Don't Know** |
| 163 | - Say "I don't understand X" |
| 164 | - Don't pretend to know |
| 165 | - Ask for help |
| 166 | - Research more |
| 167 | |
| 168 | ### Phase 4: Implementation |
| 169 | |
| 170 | **Fix the root cause, not the symptom:** |
| 171 | |
| 172 | 1. **Create Failing Test Case** |
| 173 | - Simplest possible reproduction |
| 174 | - Automated test if possible |
| 175 | - One-off test script if no framework |
| 176 | - MUST have before fixing |
| 177 | - Use the `superpowers:test-driven-development` skill for writing proper failing tests |
| 178 | |
| 179 | 2. **Implement Single Fix** |
| 180 | - Address the root cause identified |
| 181 | - ONE change at a time |
| 182 | - No "while I'm here" improvements |
| 183 | - No bundled refactoring |
| 184 | |
| 185 | 3. **Verify Fix** |
| 186 | - Test passes now? |
| 187 | - No other tests broken? |
| 188 | - Issue actually resolved? |
| 189 | - Use the `superpowers:verification-before-completion` skill before claiming success |
| 190 | |
| 191 | 4. **If Fix Doesn't Work** |
| 192 | - STOP |
| 193 | - Count: How many fixes have you tried? |
| 194 | - If < 3: Return to Phase 1, re-analyze with new information |
| 195 | - **If ≥ 3: STOP and question the architecture (step 5 below)** |
| 196 | - DON'T attempt Fix #4 without architectural discussion |
| 197 | |
| 198 | 5. **If 3+ Fixes Failed: Question Architecture** |
| 199 | |
| 200 | **Pattern indicating architectural problem:** |
| 201 | - Each fix reveals new shared state/coupling/problem in different place |
| 202 | - Fixes require "massive refactoring" to implement |
| 203 | - Each fix creates new symptoms elsewhere |
| 204 | |
| 205 | **STOP and question fundamentals:** |
| 206 | - Is this pattern fundamentally sound? |
| 207 | - Are we "sticking with it through sheer inertia"? |
| 208 | - Should we refactor architecture vs. continue fixing symptoms? |
| 209 | |
| 210 | **Discuss with your human partner before attempting more fixes** |
| 211 | |
| 212 | This is NOT a failed hypothesis - this is a wrong architecture. |
| 213 | |
| 214 | ## Red Flags - STOP and Follow Process |
| 215 | |
| 216 | If you catch yourself thinking: |
| 217 | - "Quick fix for now, investigate later" |
| 218 | - "Just try changing X and see if it works" |
| 219 | - "Add multiple changes, run tests" |
| 220 | - "Skip the test, I'll manually verify" |
| 221 | - "It's probably X, let me fix that" |
| 222 | - "I don't fully understand but this might work" |
| 223 | - "Pattern says X but I'll adapt it differently" |
| 224 | - "Here are the main problems: [lists fixes without investigation]" |
| 225 | - Proposing solutions before tracing data flow |
| 226 | - **"One more fix attempt" (when already tried 2+)** |
| 227 | - **Each fix reveals new problem in different place** |
| 228 | |
| 229 | **ALL of these mean: STOP. Return to Phase 1.** |
| 230 | |
| 231 | **If 3+ fixes failed:** Question the architecture (see Phase 4.5) |
| 232 | |
| 233 | ## your human partner's Signals You're Doing It Wrong |
| 234 | |
| 235 | **Watch for these redirections:** |
| 236 | - "Is that not happening?" - You assumed without verifying |
| 237 | - "Will it show us...?" - You should have added evidence gathering |
| 238 | - "Stop guessing" - You're proposing fixes without understanding |
| 239 | - "Ultra-think this" - Question fundamentals, not just symptoms |
| 240 | - "We're stuck?" (frustrated) - Your approach isn't working |
| 241 | |
| 242 | **When you see these:** STOP. Return to Phase 1. |
| 243 | |
| 244 | ## Common Rationalizations |
| 245 | |
| 246 | | Excuse | Reality | |
| 247 | |--------|---------| |
| 248 | | "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. | |
| 249 | | "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. | |
| 250 | | "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. | |
| 251 | | "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. | |
| 252 | | "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. | |
| 253 | | "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. | |
| 254 | | "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. | |
| 255 | | "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. | |
| 256 | |
| 257 | ## Quick Reference |
| 258 | |
| 259 | | Phase | Key Activities | Success Criteria | |
| 260 | |-------|---------------|------------------| |
| 261 | | **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY | |
| 262 | | **2. Pattern** | Find working examples, compare | Identify differences | |
| 263 | | **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis | |
| 264 | | **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass | |
| 265 | |
| 266 | ## When Process Reveals "No Root Cause" |
| 267 | |
| 268 | If systematic investigation reveals issue is truly environmental, timing-dependent, or external: |
| 269 | |
| 270 | 1. You've completed the process |
| 271 | 2. Document what you investigated |
| 272 | 3. Implement appropriate handling (retry, timeout, error message) |
| 273 | 4. Add monitoring/logging for future investigation |
| 274 | |
| 275 | **But:** 95% of "no root cause" cases are incomplete investigation. |
| 276 | |
| 277 | ## Supporting Techniques |
| 278 | |
| 279 | These techniques are part of systematic debugging and available in this directory: |
| 280 | |
| 281 | - **`root-cause-tracing.md`** - Trace bugs backward through call stack to find original trigger |
| 282 | - **`defense-in-depth.md`** - Add validation at multiple layers after finding root cause |
| 283 | - **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling |
文件内容是平台检查时读出的文本，只供查看。平台不会运行包里的任何脚本或程序。
