用途
系统化调试用于在遇到任何 bug、测试失败或意外行为时，在提出修复之前先定位并解决根本原因。它适用于各类技术问题，包括测试失败、生产环境 bug、意外行为、性能问题、构建失败和集成问题。
尤其建议在以下情况使用：有时间压力、看起来只需做一个快速修复、已经尝试过多个修复、上一个修复没有奏效、你没有完全理解问题。即便问题看起来简单、你很赶时间、或经理要求现在就修好，也不应跳过该流程。
主要能力
该技能的核心是四个必须按顺序完成的阶段：
第 1 阶段：根本原因调查。 在尝试任何修复之前，仔细阅读错误消息和完整堆栈跟踪，记录行号、文件路径、错误代码；稳定复现问题并记录精确步骤；检查最近变更（如 Git diff、最近提交、新依赖、配置变更、环境差异）。在多组件系统中，需在每个组件边界添加诊断插桩，记录进入和输出的数据，验证环境与配置传播，检查各层状态，运行一次以收集证据显示问题出在哪里，再分析证据定位失败组件。数据流追踪则沿着调用栈反向向上找到坏值的源头，并在源头修复而非在症状处修复。
第 2 阶段：模式分析。 修复前先在同一代码库中查找类似的可工作代码，与参考实现逐行比较，列出可工作部分与坏掉部分的每一个差异，并理解依赖关系（所需组件、设置、配置、环境及其假设）。
第 3 阶段：假设与测试。 形成单一假设并清楚写下“我认为 X 是根本原因，因为 Y”；做出尽可能小的改动来测试假设，一次只改一个变量；验证有效则进入下一阶段，无效则形成新假设，不在其上叠加修复。
第 4 阶段：实现。 创建失败测试用例（如可能使用自动化测试，如无框架则写一次性脚本，修复前必须有），实现单一修复，处理已识别的根本原因，一次只做一个变更，不做顺手改进、不捆绑重构；然后验证修复是否通过、是否影响其他测试、问题是否确实解决。
使用方式
该技能以流程规范形式给出。资料中包含多层系统的诊断插桩示例（Workflow、Build script、Signing script、Actual signing 四层，通过 echo、env、security list-keychains、codesign 等命令逐层收集证据）。若修复无效，则计数已尝试的修复次数：少于 3 次回到第 1 阶段；3 次及以上则停下并质疑架构，与人类伙伴讨论后再尝试新修复。资料还列出了应停下的“危险信号”（如“先快速修复之后再调查”“先试着改 X 看看是否有效”“加多个变更然后跑测试”“跳过测试手动验证”“可能是 X 让我修一下”等）、人类伙伴发出的纠偏信号（如“那没有发生吗？”“它会向我们展示……吗？”“别猜了”“深入思考这个问题”“我们卡住了吗？”）以及常见合理化借口的对照表。
适用场景
适用于任何技术问题的排查与修复，特别是多层系统中难以定位失败层的场景，以及已尝试多个修复仍无效、需要判断是否存在架构问题的情况。资料提到该技能配套以下支撑技术：root-cause-tracing.md（沿调用栈反向追踪）、defense-in-depth.md（找到根本原因后在多层添加验证）、condition-based-waiting.md（用条件轮询替代任意 timeout）；相关技能包括 superpowers:test-driven-development（用于第 4 阶段创建失败测试用例）和 superpowers:verification-before-completion（在声称成功前验证修复有效）。
限制
资料强调铁律：NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST，未完成第 1 阶段不能提出修复方案。如果系统化调查显示问题确实是环境性、时序依赖或外部问题，流程已算完成，需记录调查内容、实现适当处理（retry、timeout、error message）并添加监控/日志；但资料指出 95% 的“没有根本原因”案例其实是调查不完整。资料未提供该技能的具体平台限制、收费方式、价格或安装命令。