用途：协作调查 GitHub issue 或已报告的 bug，追踪相关代码历史、理解涉及的架构，并与用户共同判断问题是否成立、真正成因是什么。目标是双方都形成真实理解，而不只是猜测。
主要能力与流程：分多个阶段推进。阶段1识别问题，可从 $ARGUMENTS 解析 issue 编号、URL 或可选 --working-file <path>；有工作文件时先验证并读取，按其交接指令处理，返回前把发现更新回同一文件。用户可能提供 issue 编号/URL、bug 描述或什么都不提供；若无编号，会检查当前分支名是否含 issue 编号并确认。还会识别相关人员背景，如作者、评论者、指派者，检查其合并 PR 数等。阶段2搜索相关 issue 与 PR，含已关闭项以排查回归。阶段3从症状追踪代码，查错误信息、代码路径、共享状态、配置、竞态等，并用 git log、git blame、关联 PR 理清历史与架构关系。阶段4给出诊断与判断，评估问题是否成立（XY 问题、配置/用户错误、文档缺口、符合设计、真实 bug），并让用户确认。阶段5按需交互式深挖具体区域。阶段6做理解质量门，确认形成理解。阶段7写入理解文件（有工作文件则更新该文件，否则写 .issue-review/UNDERSTANDING.md）。阶段8可选发布到 GitHub，需用户确认后才发评论。
使用方式：作为技能被调用，可传入 issue 编号、URL、bug 描述或 --working-file 路径。命令示例：gh issue view <number> --json title,body,labels,comments,assignees,state,author；gh issue list --search "<keywords>"；git log --oneline -20 -- <file>；gh issue comment <number> --body "<comment>"。注意 gh 输出常含 ANSI 颜色码会破坏 jq，应使用 gh 自带 --jq 或加 NO_COLOR=1。未经明确批准不得发布评论。
适用场景：需要判断 issue 有效性、排查根因、追踪代码历史与架构关系的协作调查。
限制：资料未提供关于计费、平台支持范围、效果保证等信息；行为规则要求保持怀疑、追踪而非猜测、允许多个原因、回复简短、以假设驱动，并由用户决定探索方向。