用途：在动手改代码之前，对已报告的缺陷、报错、测试失败或异常行为做根因分析，避免盲目尝试修复掩盖真实问题。适用于测试失败、生产 bug、异常行为、性能问题、构建失败等技术问题，尤其在时间紧张而诱使人猜测、看似有“快速修复”、此前修复无效或问题尚未被完全理解时更有价值。
四阶段：1) 根因调查——先查阅记忆（memory），仔细读完整错误信息，稳定复现，检查近期变更（git diff、新依赖、配置、环境差异），在多组件系统中于各组件边界加诊断日志收集证据，并沿调用栈向上追踪数据流直到源头；2) 模式分析——在代码库中寻找可用的同类实现，完整阅读参考实现，列出正常与异常代码的全部差异，理解依赖与假设；3) 假设与验证——提出单一假设（“X 是根因，因为 Y”），做最小改动、一次只改一个变量，验证通过再进入下一阶段，否则重新提出假设；4) 实施——先写能捕获该缺陷的最简失败测试，再针对根因做单一修复，验证通过且不破坏其他测试。若修复仍无效，尝试少于 3 次则回到第一阶段重新分析；达到 3 次以上则质疑架构。
铁律：未完成根因调查不得提出修复。每个阶段必须完成后再进入下一阶段。
用法：以 /superpowers:systematic-debugging "<症状>" 调用；作为斜杠命令时把 $ARGUMENTS 作为症状陈述并立即从第一阶段开始，不写设计文档或任务文件，交付物是修复加上捕获回归的测试。建议包在 /goal 中运行，使多轮“假设→验证→修复”持续到回归真正修好。/goal 是用户手动输入的外层包装（技能无法在运行中自行启用），其判定只依据对话中叙述的内容，条件应针对叙述输出（打印的测试结果、三段式总结），而非文件系统状态。
豁免检查：在第一阶段前检查 $ARGUMENTS 是否同时满足——指出了具体根因（文件:行、配置键或具体值）、指出了具体纠正改动、修复局限于单文件或单处字符串替换；三者全部满足则跳过四阶段直接修复并写回归测试。传入 --force 时跳过该豁免，无条件进入第一阶段。
复杂缺陷需在改动前以内联形式记录六行计划（根因、修复策略、文件、测试、风险、备选），不写入文件、不暂停等待批准；证据不足以填写任一行时回到第一阶段。
输出规范：每完成一阶段即内联报告发现，最终以 (a) 根因一句话、(b) 修复 diff 摘要、(c) 回归测试路径结尾。若系统化调查表明问题属于环境、时序或外部因素，则记录调查内容并实现相应处理与监控日志。具体限制、费用与平台信息暂未提供。