用途：该技能用于对 GitHub Issue 进行比初筛更深入的调查，对照实际代码验证 Issue 中的主张、确认根因并给出修复方向。产出为一条评论，结论为已确认、驳回（无法复现/已修复/前提错误）或需要更多信息。
何时使用：Issue 内容稀疏、引用的文件与行号可能已变动、问题超过三个月需确认是否仍存在、准备分配修复分支前需要可靠方向，或用户要求 investigate、deep-dive、verify 时。若只需轻量初筛（内容完整、主张明确、仅需打标签）则不要使用。
主要流程：完整阅读正文并记录每条主张（文件路径与行号、复现步骤、建议修复、影响范围）；逐一打开对应文件行确认代码是否仍存在、是否被移动或重构、缺陷是否仍在，并尽量运行复现步骤；不要信任正文列举的范围，用 grep、Glob 搜索同类反模式，用 git blame 查看相关改动时间，检查相关测试是否存在、能否捕获该问题；据此决定结论。
评论模板：包含标题（含日期）、Verdict、调整后的优先级，以及按需出现的 At a Glance 图示、Verified 已验证项、Body inaccuracies、Proposed Direction、Open Questions、Related 等小节；不适用的段落应省略而非填 N/A。
与初筛的区别：调查会阅读代码、验证文件行号、探测影响范围并提出独立分析，每个问题约需 30 分钟至数小时，不适合对整个待办列表执行。
限制与常见错误：不要只信正文中的文件行号，代码会变动；不要止步于正文建议的修复；不要跳过影响范围；不要提出未经在 HEAD 验证的推测性修复，无法验证时应打 status/needs-info 并停止；不要在 Proposed Direction 中埋藏真正的取舍或验证缺口，应放入 Open Questions。资料未提供安装命令、收费与具体平台信息。