用途
系统化调试用于处理任何技术问题，包括测试失败、生产环境 bug、异常行为、性能问题、构建失败和集成问题。它的核心目标是：在尝试修复之前，务必先找到根本原因，只修症状就是失败。
该技能特别强调在以下情况必须使用：时间紧迫、觉得“一个小修改”就能搞定、已经尝试了多种修复、上一次修复没有生效、没有完全理解问题。即使问题看起来很简单、你很赶时间、或领导要求立刻修好，也不应跳过流程。
主要能力
该技能提供一套四阶段调试流程，每个阶段必须完成才能进入下一个：
- 根因调查：仔细阅读错误信息、完整阅读堆栈跟踪、稳定复现问题、检查近期变更、在多组件系统中收集证据、跟踪数据流。
- 模式分析：找到可正常工作的示例、与参考实现对比、识别差异、理解依赖关系。
- 假设与验证：提出单一假设、最小化测试、每次只改一个变量、继续之前先验证。
- 实施：创建失败的测试用例、实施单一修复、验证修复。
此外，技能还包含辅助技术文档：root-cause-tracing.md（沿调用栈反向追踪 bug）、defense-in-depth.md（在多个层级添加校验）、condition-based-waiting.md（用条件轮询替代硬编码等待时间）。
使用方式
该技能以流程规范的形式使用。当遇到技术问题时，按照四个阶段依次执行。在根因调查阶段，需要阅读错误信息、复现问题、检查变更、收集证据；在模式分析阶段，找到正常代码与问题代码的差异；在假设与验证阶段，提出假设并做最小化测试；在实施阶段，先创建失败测试，再实施单一修复，最后验证。
技能中给出了多层系统诊断埋点的示例代码，用于在组件边界记录进入和离开的数据、验证环境/配置传递、检查每一层状态。
如果修复不起作用，需要停下来计数：少于 3 次回到第一阶段重新分析；3 次或以上则质疑架构，在没有经过架构讨论前不要尝试第 4 次修复。
适用场景
适用于任何技术问题，包括测试失败、生产环境 bug、异常行为、性能问题、构建失败、集成问题。尤其在时间紧迫、问题看似简单、已尝试多种修复、上一次修复无效、没有完全理解问题等情况下必须使用。
限制
该技能强调不做根因调查就不许提修复方案。如果系统化排查后发现问题确实是环境相关、时序相关或外部因素导致的，可以记录排查内容、实施适当处理措施并添加监控/日志，但技能指出 95% 的“找不到根因”其实是排查不充分。
技能中提到的相关技能包括 superpowers:test-driven-development（用于创建失败测试用例）和 superpowers:verification-before-completion（在宣称成功之前验证修复确实有效）。
关于该技能的收费、价格、平台支持等具体信息，资料中暂未提供。