Menu
遇到任何 bug、测试失败或意外行为时使用，在提出修复之前先进行系统化调查
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
在实现完成、测试通过后，引导决定如何集成工作——提供合并、PR 或清理的结构化选项
| name | systematic-debugging |
| description | 遇到任何 bug、测试失败或意外行为时使用，在提出修复之前先进行系统化调查 |
随机修复浪费时间并制造新 bug。快速补丁掩盖底层问题。
核心原则： 在尝试修复之前，必须先找到根因。修复症状就是失败。
违反此流程的字面意思就是违反调试的精神。
没有根因调查，不得进行任何修复
如果你没有完成阶段 1，就不能提出修复方案。
用于任何技术问题：
尤其在以下情况使用：
不要跳过，即使：
你必须完成每个阶段后才能进入下一个。
在尝试任何修复之前：
仔细阅读错误信息
稳定复现
检查近期变更
在多组件系统中收集证据
当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
在提出修复之前，添加诊断插桩：
对每个组件边界：
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置的传递
- 检查每一层的状态
运行一次以收集证据，展示哪里断了
然后分析证据以识别故障组件
然后调查那个特定组件
示例（多层系统）：
# 第 1 层：工作流
echo "=== 工作流中可用的 Secrets: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# 第 2 层：构建脚本
echo "=== 构建脚本中的环境变量: ==="
env | grep IDENTITY || echo "IDENTITY not in environment"
# 第 3 层：签名脚本
echo "=== Keychain 状态: ==="
security list-keychains
security find-identity -v
# 第 4 层：实际签名
codesign --sign "$IDENTITY" --verbose=4 "$APP"
这揭示了： 哪一层失败（secrets → 工作流 ✓，工作流 → 构建 ✗）
追踪数据流
当错误深在调用栈中时：
参见本目录下的 root-cause-tracing.md 了解完整的反向追踪技术。
快速版本：
在修复之前找到模式：
找到可工作的示例
对照参考比较
识别差异
理解依赖
科学方法：
形成单一假设
最小化测试
继续之前验证
当你不确定时
修复根因，而非症状：
创建失败的测试用例
test-driven-development skill 编写正确的失败测试实现单一修复
验证修复
如果修复无效
如果 3 次以上修复失败：质疑架构
表明架构问题的模式：
停下来质疑基本面：
在尝试更多修复之前与用户讨论
这不是假设失败——这是架构错误。
如果你发现自己在想：
以上所有都意味着：停下来。回到阶段 1。
如果 3 次以上修复失败： 质疑架构（见阶段 4.5）
注意这些来自用户的提示：
当你看到这些时： 停下来。回到阶段 1。
| 借口 | 现实 |
|---|---|
| "问题很简单，不需要流程" | 简单问题也有根因。流程对简单 bug 也很快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测式乱试更快。 |
| "先试这个，然后再调查" | 第一次修复设定了模式。从一开始就做对。 |
| "修复确认有效后再写测试" | 未测试的修复不持久。先测试证明它。 |
| "同时修复多个省时间" | 无法隔离什么起了作用。会引入新 bug。 |
| "参考太长了，我改编一下模式" | 部分理解保证有 bug。完整阅读。 |
| "我看到了问题，让我修复它" | 看到症状 ≠ 理解根因。 |
| "再试一次修复"（2 次以上失败后） | 3 次以上失败 = 架构问题。质疑模式，而非再次修复。 |
| 阶段 | 关键活动 | 成功标准 |
|---|---|---|
| 1. 根因 | 阅读错误、复现、检查变更、收集证据 | 理解了什么和为什么 |
| 2. 模式 | 找到可工作的示例、比较 | 识别了差异 |
| 3. 假设 | 形成理论、最小化测试 | 确认或形成新假设 |
| 4. 实现 | 创建测试、修复、验证 | Bug 解决，测试通过 |
如果系统化调查揭示问题确实是环境性的、时序依赖的或外部的：
但是： 95% 的"没有根因"情况是调查不充分。
这些技术是系统化调试的组成部分，位于本目录下：
root-cause-tracing.md — 通过调用栈反向追踪 bug 以找到原始触发点defense-in-depth.md — 找到根因后在多个层添加验证condition-based-waiting.md — 用条件轮询替代任意超时相关 skill：
来自调试会话：