systematic-debugging
在修復前先系統化調試以找出根本原因
也可從以下取得: Cygnusfear,Cycleaddict,Doyajin174,DMJGilbert,Asmayaseen,DYAI2025,davila7,CodingCossack,obra,ChrisWiles
隨機修復會浪費時間並產生新的錯誤。此技能提供一個四階段調試框架，在實施解決方案前找出根本原因，避免在基於症狀的修復上浪費精力。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「systematic-debugging」。 測試失敗，git init 錯誤出現在錯誤目錄
預期結果:
- 第一階段 - 根本原因調查：
- 1. 錯誤顯示 git init 在 /source/code 而非 /tmp 執行
- 2. 向後追蹤：git init <- WorktreeManager <- Session.create <- 測試
- 3. 發現：projectDir 是空字串，解析為 process.cwd()
- 4. 根本原因：測試在 beforeEach 初始化前存取 context.tempDir
- 根本原因已識別：變數初始化順序問題
正在使用「systematic-debugging」。 不穩定測試有時錯過工具結果
預期結果:
- 診斷：測試使用任意 setTimeout 等待而非條件檢查
- 解決方案：以條件式等待取代超時
- Before: await new Promise(r => setTimeout(r, 300))
- AFTER: await waitForEventCount(threadManager, id, 'TOOL_RESULT', 2)
- 結果：60% 通過率提升至 100%
安全審計
低風險Static analyzer flagged 126 patterns but 125 are false positives from markdown documentation (backticks are code formatting, not shell execution). One legitimate shell script (find-polluter.sh) uses npm test for test debugging - acceptable for a debugging skill. No cryptographic code exists despite scanner claims. Skill teaches debugging methodology safely.
低風險問題 (1)
風險因素
⚙️ 外部命令 (1)
品質評分
你能建構什麼
測試失敗調查
當測試間歇性或意外失敗時，使用此技能系統化地追蹤失敗回到根本原因，而非套用快速修復。
生產環境錯誤解決
當錯誤出現在生產環境時，遵循四階段流程以了解根本原因，再部署可能產生新問題的修復。
多組件調試
當調試具有多層次的複雜系統時，使用縱深防禦診斷來精確識別哪個組件失敗。
試試這些提示
我看到這個錯誤：[貼上錯誤]。我想快速修復它，但我知道我應該先調查。協助我遵循系統化調試的第一階段，在提出任何修復前了解根本原因。
這個測試間歇性失敗：[貼上測試]。有時通過，有時失敗。引導我進行系統化調試以找出導致不穩定的原因，包括如何新增診斷工具。
我已經嘗試了 [N] 次修復但都沒成功。每次修復都揭示了新問題。協助我停下來質疑是否有架構問題，而非嘗試另一個修復。引導我從第一階段重新分析。
最佳實務
- 在完成第一階段調查前絕對不要提出任何修復 - 了解根本原因比隨機修復更有效率
- 向後追蹤錯誤通過呼叫堆疊以找出原始觸發點，而非僅是錯誤出現的位置
- 在 3 次修復嘗試失敗後，停下來質疑架構而非嘗試更多症狀修復
避免
- 在完成根本原因調查前提議修復 - 這只是治療症狀而非原因
- 一次進行多項變更 - 你無法隔離什麼有效，並可能引入新錯誤
- 跳過建立失敗測試 - 未經驗證的修復無法持久且回歸不易被察覺