用途：在尝试修复前先调查 GitHub issue，确认报告的问题真实且可复现，查找根因，并检查是否已存在修复。该技能聚焦调查与复现；标签、优先级和分派请见 doc-triage-agent。
主要流程：
- 仔细阅读 issue，提取症状、位置（URL、文件路径、版本）、提交日期、指派人与评论。
- 复现问题：按类型选择方法——失效链接/404 抓取线上 URL；内容错误对比线上页面；渲染/布局问题在浏览器查看；缺失页面在仓库搜索；CI 链接检查失败读 CI 日志。若问题已不存在，查 git 历史确认何时修复再关闭。
- 检查代码库：搜索相关文件、查看 git 历史，命令如 git log --oneline -20 -- <path>、git log --follow --oneline -- <path>，并搜索引用该 issue 编号的 PR：git log --oneline --all | grep <issue-number>。
- 定位根因：常见模式包括 404（缺页、Hugo alias 错误、URL 错误）、片段找不到（标题重命名或删除）、内容错误（过时文案、共享内容陈旧）、渲染 bug（shortcode 误用、模板错误）、文档缺失（页面未创建或被删除）。
- 决定结果：仍损坏则描述根因并提最小修复；已修复则指出对应提交/PR 并建议关闭；非文档问题（权限、外部站点、产品 bug）建议转派或说明后关闭；无法复现则说明已检查内容并请求澄清。
限制与注意：不要把未关闭的 issue 当作问题仍存在的证据；未复现前不要直接修复；不要先重构内容（重命名目录、移动文件），应先确认 alias、重定向或内容编辑等更简单方案是否已处理；不要混淆访问错误（403）与内容缺失（404）。