用途：该技能是 autofix 链（verify-in-repo → root-cause → apply-fix → open-pr → auto-review-pr）的第 2 步。前一步已确认是真实缺陷，仓库已检出到隔离分支。它唯一的任务是找出根因并定义最小改动集，让下一步 apply-fix 有所依据。
主要能力：只读方式阅读文件与搜索代码，不做文件编辑或写入；只读执行 gh 与 git（git log、git diff、git show、git status、git blame）；不编辑、不提交、不推送。流程为：用 gh issue view 拉取 Issue 上下文；只读取受影响区域的代理说明与贡献文档（如 CLAUDE.md、CONTRIBUTING.md）以及设计文档，能确定涉及文件后即停止；追踪产生该行为的代码路径，从入口（路由、处理函数、导出函数、测试）搜索并阅读周边代码，留意偏离项目自身约定的地方（如绕过数据访问、校验或安全辅助函数）；若复现成本低则确认缺陷，但不运行昂贵的验证套件。
使用方式：参数 {issueId}（必填，GitHub Issue 编号）、{repo}（可选，owner/name，省略时从 git remote 推断）。输出为纯文本最终消息，固定结构：Summary（一句话）、Root cause（一段说明代码位置与为何产生错误行为）、Files to change（文件路径及改动内容，含回归测试）、Approach（2–4 句最小编辑说明，引用函数名、条件与行为变化，并说明须遵守的代理指令或设计文档约束）、Risks（一段，说明可能出错点、需验证项与破坏性变更顾虑）。整体约 400 词以内。
适用场景：GitHub Issue 的缺陷定位与修复规划，尤其配合自动修复链使用。
限制：只读，不改文件与 git/GitHub 状态；不得提议跨无关区域改动，若问题涉及多方面则选最小可辩护的主修复并将其余列入 Risks；须引用真实文件路径与函数名，否则会迫使后续代理重新探索；无法确定根因时以 LOW_CONFIDENCE 结尾并给出最佳猜测分析。