用途
systematic-debugging 是一个面向复杂或顽固缺陷的调试技能。当多次修复或调试尝试已经失败时，它采用改良版 Fagan 审查方法进行系统化的问题定位与解决，而不是继续快速试错。官方描述指出，它适用于解决持续存在的缺陷和复杂问题。
主要能力
技能将调试过程划分为四个阶段，要求为每个阶段创建任务，并依次完成、逐个标记后进入下一阶段，不允许跳过阶段或在完成审查前尝试修复。
阶段一：初始概览
在分析前建立对问题的清晰理解，包括：用不含技术术语的朴素语言解释问题；说明预期行为；说明实际行为；记录症状，如错误信息、日志、可观察到的失败；记录上下文，即问题在何时出现、出现频率、在什么条件下出现；列明此前的修复尝试，包括每次尝试改动了什么以及为什么失败，并将这些尝试视为已被排除的假设，阶段三必须将其纳入考虑。此阶段的输出是一份任何人都能理解的问题陈述。
阶段二：系统审查
以 Fagan 审查中的 Reader 角色进行逐行走查，只识别缺陷，不尝试修复，属于纯审查。检查的缺陷类别包括：逻辑错误、边界条件、错误处理、数据流问题、集成点。过程中要求边想边说：说明每段代码意图做什么；找出意图与实现之间的差异；标记假设或不明确之处；对复杂部分使用 ultrathink 进行更深思考。输出是按类别整理的缺陷列表，附带行号和具体描述。
阶段三：根因分析
在识别问题后，追溯根本原因而非停留在症状。技能推荐 Five Whys 技术，反复询问“为什么”（至少三到五次），并明确写出每一次“为什么”。示例链条为：API 调用为什么失败？因为请求格式错误；为什么格式错误？因为数据未被正确序列化；为什么未序列化？因为序列化器期望的类型不同；为什么期望不同类型？因为模式已更新但代码未更新；根因为服务之间的模式版本不匹配。同时需考虑环境因素（配置、依赖、运行时环境）、时序与并发（竞态条件、异步问题）、代码或系统设计中的隐藏假设、历史背景（近期变更、迁移、更新）。所有假设需显式说明，例如“我假设 X 是因为……”“这假定 Y 始终……”，并标记需要验证的假设。输出是根因的清晰陈述、推导链条以及需要验证的假设。
阶段四：解决方案与验证
针对每个识别出的问题提出具体修复。每个方案需说明：修复内容，即需要哪些代码或配置改动；为什么能解决根因，并与阶段三分析关联；可能的副作用；验证步骤。验证计划包括：本可捕获该缺陷的具体测试用例、人工验证步骤、需要添加的监控或日志、需要验证的边界情况。技能还建议使用子智能体作为“回音板”，对提出的方案和验证计划给出批评性反馈。输出包括发现摘要（关键缺陷与根因）、按优先级排列的修复列表及理由、确认修复有效的验证计划。
使用方式
在支持该技能的环境中调用 systematic-debugging，然后按四个阶段依次推进。技能要求在进入下一阶段前完整完成当前阶段；对不确定之处应标记而非猜测；应使用可用工具，如读取文件、搜索代码、运行测试、检查日志；优先系统分析而非快速修复。在所有阶段完成后，技能建议回头复查此前标记的不明确点，必要时用 think 工具以“ultra”深度澄清。除非用户另有指示，完成四个阶段后即着手实施所提出的解决方案。
适用场景
- 多次修复或调试尝试已经失败的顽固缺陷。
- 复杂、难以定位的问题。
- 需要对既有代码进行系统化审查的调试场景。
限制
技能明确列出不应使用该技能的情况：简单、明显且修复方式清晰的缺陷；首次调试尝试仍在进行中；开发新功能（本技能用于调试既有代码）；问题明显属于环境层面（配置、基础设施）且不需要代码审查。
暂未提供的信息
资料未提供该技能支持的平台与运行环境限制、收费或价格信息，也未提供具体的安装命令或配置步骤。