用途：引导智能体按五阶段流程定位并验证问题根因，最终产出可持久保存的修复提案。适用于报告 bug、错误、崩溃或异常行为时。
主要能力与流程： 阶段1 信息收集：通过 AskUserQuestion 逐项询问预期行为、实际现象（含原始报错）、起始时间与近期变更、环境、是否可稳定复现、相关代码或日志；未提供的信息才询问，允许回答 unknown 但需记录。六项未完成前不进入下一阶段。 阶段2 调查：纯观察，不下结论。先读 README、CONTRIBUTING、docs/、.cursorrules、.claude/ 等了解约定，识别测试框架与运行命令、命名与断言风格，检查 .specs/ 是否已有同类报告，再阅读堆栈、源码、配置、日志与环境变量，并记录缺失日志、静默失败等“缺席证据”。 阶段3 假设：列出 3–5 个根因候选，按置信度（高/中/低）排序，每条附具体证据。若全部为低置信度，先提一个针对性问题。 阶段4 验证：从高到低逐条验证，按项目既有测试框架编写可运行的最小测试用例，隔离单一失败行为并显式断言预期与实际。确认即停止并进入阶段5；被否定则继续下一条；全部否定则回到阶段2。未复现前不得提出修复；确实无法复现时需说明尝试过程，可给出低置信度修复并注明复现缺口。 阶段5 提出并保存：用 kebab-case 命名 bug，检查 .specs/bugs/[bug-name].md 是否存在，存在则用 -2 后缀，必要时创建目录，按模板写入根因、置信度、复现、修复步骤与预防措施，并告知用户完整路径。
限制与注意：不得在验证前提出修复；不得因问题看似明显而跳过复现；低置信度假设不得视为已确认；一次只问一个澄清问题；测试须遵循项目既有风格；报告须在阶段4完成后才保存。
分类：该技能用于缺陷诊断与调试工作流，归入测试与质量。