Menu
在遇到任何 bug、测试失败或意外行为时使用，在提出修复方案之前先进行系统排查
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
桌面/网关运行时内置的计划创建技能，用于生成可落盘、可调度、可批次执行的结构化计划包。
桌面/网关运行时内置的计划执行技能，用于按批次执行结构化计划包中的单个任务文件。
Use when demonstrating or verifying VibeWindow local plugin packaging, including plugin skills, MCP servers, hook declarations, and interface metadata.
当需要在编码前创建或更新实施计划时使用，尤其适用于多步骤功能开发、重构、包含多个活动部件的缺陷修复，或需要拆分为可独立执行并跟踪进度的任务文件的请求。
当你有书面实现计划需要在单独会话中执行，并带有审查检查点时使用
通过 `rustcodegraph` 命令行界面使用 RustCodeGraph 理解、导航或脚本化操作已索引代码库。当用户要求使用 RustCodeGraph、需要高性能搜索检索代码、需要符号/源码/调用流上下文、调用方/被调用方/影响分析或受影响测试选择时使用。
| name | systematic-debugging |
| description | 在遇到任何 bug、测试失败或意外行为时使用，在提出修复方案之前先进行系统排查 |
随机修复浪费时间并制造新的 bug。快速补丁掩盖了潜在问题。
核心原则： 始终在尝试修复之前找到根因。修症状而非根因就是失败。
违反此流程的字面意义就是违反调试的精神。
没有根因调查就不能提出修复方案
如果你还没有完成第一阶段，就不能提出修复方案。
用于任何技术问题：
特别适用于以下情况：
不要跳过的理由：
你必须在进入下一阶段之前完成每个阶段。
在尝试任何修复之前：
仔细阅读错误信息
稳定复现
检查近期变更
在多组件系统中收集证据
当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
在提出修复方案之前，先添加诊断工具：
对于每个组件边界：
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置的传播
- 检查每一层的状态
运行一次以收集显示在哪里断裂的证据
然后分析证据以识别失败的组件
然后调查该特定组件
示例（多层系统）：
# 第一层：工作流
echo "=== 工作流中可用的密钥： ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# 第二层：构建脚本
echo "=== 构建脚本中的环境变量： ==="
env | grep IDENTITY || echo "IDENTITY 不在环境中"
# 第三层：签名脚本
echo "=== 钥匙串状态： ==="
security list-keychains
security find-identity -v
# 第四层：实际签名
codesign --sign "$IDENTITY" --verbose=4 "$APP"
这揭示了： 哪一层失败（密钥 → 工作流 ✓，工作流 → 构建 ✗）
追踪数据流
当错误在调用栈深处时：
参见本目录中的 root-cause-tracing.md，了解完整的反向追踪技术。
简略版本：
在修复之前找到模式：
找到可工作的示例
与参考对比
识别差异
理解依赖关系
科学方法：
形成单一假设
最小化测试
验证后继续
当你不知道时
修复根因，而非症状：
创建失败的测试用例
superpowers:test-driven-development 技能来编写正确的失败测试实现单一修复
验证修复
如果修复不起作用
如果3次以上修复都失败：质疑架构
表明架构问题的模式：
停止并质疑根本问题：
在与你的人类伙伴讨论之后再尝试更多修复
这不是失败的假设 - 这是错误的架构。
如果你发现自己在想：
所有这些都意味着：停止。返回第一阶段。
如果3次以上修复失败： 质疑架构（见第四阶段第5步）
注意这些重定向：
当你看到这些：停止。返回第一阶段。
| 借口 | 现实 |
|---|---|
| "问题很简单，不需要流程" | 简单问题也有根因。流程对简单 bug 很快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测-检查的乱撞更快。 |
| "先试这个，然后调查" | 第一次修复设定模式。从一开始就做对。 |
| "确认修复有效后再写测试" | 未经测试的修不稳。先写测试来证明。 |
| "同时多个修复节省时间" | 无法隔离什么有效。会引起新 bug。 |
| "参考太长，我来适配模式" | 部分理解必定产生 bug。完整阅读。 |
| "我看到问题了，让我修" | 看到症状 ≠ 理解根因。 |
| "再试一次修复"（2次以上失败后） | 3次以上失败 = 架构问题。质疑模式，不要再修。 |
| 阶段 | 关键活动 | 成功标准 |
|---|---|---|
| 1. 根因 | 阅读错误、复现、检查变更、收集证据 | 理解是什么和为什么 |
| 2. 模式 | 找到可工作的示例、对比 | 识别差异 |
| 3. 假设 | 形成理论、最小化测试 | 确认或新假设 |
| 4. 实现 | 创建测试、修复、验证 | Bug 解决，测试通过 |
如果系统化调查揭示问题确实是环境性的、时序依赖的或外部的：
但是： 95% 的"没有根因"案例是调查不完整。
这些技术是系统化调试的一部分，可在本目录中找到：
root-cause-tracing.md - 通过调用栈向后追踪 bug 以找到原始触发点defense-in-depth.md - 在找到根因后在多个层添加验证condition-based-waiting.md - 用条件轮询替代任意超时相关技能：
来自调试会话：