修bug别只修症状！用这个Skill追到根因再动手

你有没有过这种经历——bug 明明修好了，过两天又冒出来？或者测试跑着跑着，突然多了一个奇怪的 `.git` 文件，怎么都找不到是谁创建的？

大多数时候，我们修的是症状，不是根因。

这个 Skill 解决什么问题

root-cause-tracing 是一个专门教 AI 调试的 Skill。它的核心思路很简单：不要在报错的地方修，要一直往回追溯，找到第一个出错的动作。

举个例子：你在 `packages/core/` 里发现无缘无故多了个 `.git` 文件。按直觉，你会去删掉它、或者在 git 操作的地方加判断。但这个 Skill 会带你这样追溯：

• git init 报错的地方在哪？——在 WorktreeManager
• WorktreeManager 谁调用的？——Session.initializeWorkspace()
• Session.create() 谁调用的？——测试代码
• 传进来的 projectDir 是什么？——空字符串！
• 空字符串哪来的？——setupCoreTest() 初始化时返回了 tempDir: ”

然后你发现，原来测试的 beforeEach 还没跑，变量就被访问了。修到这里，bug 才真正消失。

怎么用

装上之后，遇到任何深层 bug，直接说：

用 root-cause-tracing 帮我分析这个问题

Skill 会引导你一步一步回溯，从「报错的地方」找到「第一个触发错误的地方」。

如果调用链太深，手动追溯不出来，它还教你加 stack trace 打印——用 console.error 打在危险操作之前，然后跑测试抓日志。

什么时候用

• 错误发生在调用链深层，不在入口点
• 测试污染：某个测试改了全局状态影响其他测试
• 数据不对劲但找不到谁改的
• 同一个 bug 反复出现，每次修每次还在

安装

curl -o ~/.claude/skills/root-cause-tracing/SKILL.md 
  "https://raw.githubusercontent.com/composio-community/support-skills/HEAD/root-cause/SKILL.md"

然后重启 Claude Code，自动发现。

最后

这个 Skill 的价值不在于告诉你答案，而在于教你一套系统化的调试思维——先观察症状、找直接原因、问谁调用的这个、一直回溯到源头，再在源头修复，加防御层。

修 bug 修得快，不如修得准。

GitHub：https://github.com/composio-community/support-skills/tree/HEAD/root-cause

GitHub: https://github.com/composio-community/support-skills/tree/HEAD/root-cause