系统化调试
先找根因，再修复故障，减少反复试错。
技能强调先调查、逐层追踪和在三次失败后与人类伙伴讨论，降低盲目修改风险；但示例要求记录环境变量、密钥可用性、密钥链状态和调用栈，未说明敏感数据脱敏、最小权限、用户确认、回滚或数据保留边界，因此扣分。
四阶段流程、超时反馈和异常时返回调查流程较清晰，支持文件在给定材料中存在；但脚本依赖Unix、find、npm和特定项目测试命令，存在参数边界、路径空格、测试隔离及轮询语义未充分处理等问题，且静态审查不能证明关键路径可运行，因此不超过10分并扣分。
触发场景、反模式和不适用的真实计时测试均有说明，适合常见软件调试；但“任何技术问题”过于宽泛，未充分声明不适合的生产应急、不可复现问题或非代码故障边界，也未提供中文支持或大陆网络环境适配证据，因此扣分。
文档结构清晰，包含阶段、速查表、辅助技术、示例脚本、MIT许可证和仓库级版本信息；但选定技能缺少独立的安装/依赖说明、版本策略、变更记录、维护责任和更新路径，且创建日志中的测试与成效声明无法由文件独立核验，因此扣分。
该技能提供可直接执行的根因调查、假设测试和验证清单，理论上能减少猜测式修复；但静态材料未证明代表性输出或实际结果，且强制完整流程可能在简单或高紧急度事件中增加成本，效果声明仍需较多人工判断，因此扣分。
源文件之间对流程和辅助技术相互印证，创建日志提供了测试设计；但没有可核验的测试运行记录、CI覆盖选定技能关键路径或第三方复现证据，且“95%”“60%到100%”等结果仅为作者声明，因此只能给有限分数。
- 示例中的诊断日志可能暴露环境变量、签名身份、目录、调用栈或其他敏感运行信息；实施前应定义脱敏、访问控制和日志生命周期。
- “任何技术问题”和绝对化的“不得修复”规则可能与生产应急、不可复现故障或已有安全缓解措施冲突，应明确升级、止损和回滚条件。
- 创建日志及真实影响数据未附可复现测试产物，不能据此视为已独立验证。
这个 Skill 能做什么，适合哪些场景？
系统化调试是一套面向技术问题的四阶段排查流程。它要求先阅读错误、稳定复现问题、检查近期变更并追踪数据流，再分析模式、提出单一假设并进行最小化验证。确认根因后，流程要求创建失败测试、实施单一修复并验证结果。若连续三次以上修复失败，它要求暂停继续打补丁，转而讨论架构是否存在根本问题。
它指导代理完整阅读错误信息和堆栈、记录复现步骤、检查 Git diff 与近期提交，并在多组件系统中为边界添加诊断日志，确认数据和配置在各层的输入输出。随后它要求寻找可工作的示例、逐项比较差异、写出单一根因假设，并用最小变更逐一测试。根因确认后，它要求创建最简失败测试，实施单一修复，运行测试并确认没有引入其他故障；必要时读取同目录中的 root-cause-tracing.md、defense-in-depth.md 和 condition-based-waiting.md。
- 开发者遇到无法解释的测试失败，需要先判断问题来自代码、配置还是环境。
- 维护生产故障的工程师需要通过日志和数据流定位具体失效组件。
- 正在排查构建失败或集成问题的团队，需要比较工作路径与失败路径的差异。
- 已经尝试多次修复但问题持续出现的开发者，需要判断是否应质疑当前架构。
- 在时间压力下处理紧急缺陷的工程师，需要避免猜测式修补造成更多返工。
这个 Skill 有哪些优点和局限？
- 覆盖测试失败、生产 bug、性能问题、构建失败和集成问题。
- 明确要求复现、证据收集、数据流追踪和单一假设验证。
- 把失败测试、单一修复和回归验证纳入实施阶段。
- 连续三次以上修复失败时要求讨论架构，避免无限叠加补丁。
- 流程要求完整完成每个阶段，简单问题也不能直接跳到修复。
- 需要能够读取项目文件并运行 shell 命令；具体测试框架未指定。
- 文档声称有 15–30 分钟修复时间和 95% 首次修复率，但未提供可核验的实验方法。
- 同目录支持文件和相关技能的具体内容未在本资料中提供。
如何安装这个 Skill？
该仓库是包含 14 个技能的集合，README 未提供 systematic-debugging 的独立安装命令。使用时应按目标 coding agent 的方式安装 Superpowers 集合；README 明确说明不同 harness 需要分别安装。仓库许可证为 MIT。
如何使用这个 Skill？
在遇到 bug、测试失败或意外行为时触发。例如："我有一个持续失败的集成测试，请先严格执行 systematic-debugging 的 Phase 1，不要提出修复方案。" 在完成根因调查前，不应提出修复；之后按四个阶段推进。
这个 Skill 与同类方案有什么区别？
相较于随机尝试修复，它强调先建立证据链、定位根因，再进行最小变更和验证。