用途：系统化盘点、分类和整理 GitHub 仓库的开放 Issue，把零散待办整理成可决策的清单。
主要能力（按五步工作流）： 第一步 了解现状：用 gh CLI 拉取全部开放 Issue 并汇总积压情况。注意 gh issue list --limit 是上限、默认仅 30，超出会被静默省略；可先以较大 limit 计数：gh issue list --state open --limit 100000 --json number --jq 'length'。大仓库可用 gh api --paginate "repos/{owner}/{repo}/issues?state=open&per_page=100" | jq -s 'add | [.[] | select(.pull_request | not)]'，先合并分页再排除 PR。本阶段仅分“CodeRabbit 生成”和“人工报告”两个高层桶。 第二步 分类：按从上到下首个匹配的规则，将每个 Issue 划为 CodeRabbit 生成（作者 coderabbitai 或标签含 coderabbit；github-actions[bot] 等其他机器人不算，归入 Other）、人工报告的 bug（bug 标签，或标题含 bug/defect/failure/broken）、功能请求（enhancement/feature）、Epic/重构（refactoring/epic，或标题含 Phase/refactoring）、Other（其余，含 Dependabot 等非 CodeRabbit 机器人）。给出对应 jq 提取命令。 第三步 分组：按代码区域、根因、工作粒度把相关 Issue 归组，输出主题、相关 Issue 编号、根因、处理建议与工作量估计。 第四步 判断可关闭项：必须阅读当前代码，不能只凭 PR 历史、提交信息或标题。提取目标文件、符号、问题与代码片段；用 test -f、rg -n 检查现状；找不到时用 git log --follow -M、git log -S、git log -G 追踪重命名或移动，确认删除后才标 Target gone；用 sed 或文件读取查看相关代码。每条记录状态：Closable、Target gone、Unresolved、Needs confirmation、Duplicate，并给出证据格式。关闭时按指定格式附加代码验证说明。 第五步 报告：输出分类计数表（含可关闭数与剩余数）、可关闭候选表、分组详情与优先级建议（高：安全或正确性；中：设计与可维护性；低：风格与小改进）。
限制：关闭动作必须经用户批准，技能只做准备分析；代码判断不依赖 PR 标题或提交日志；符号工具 Serena 仅为可选辅助，非必需；资料未提供自动关闭、定价或平台细节。