Menü
遇到任何 bug、测试失败或意外行为时使用，在提出修复之前先进行系统化调查
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
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：
来自调试会话：