用途：将嘈杂的 GitHub issue 追踪器转化为主题级情报，识别系统最薄弱、最值得投入的领域。输出的是主题而非单条工单，例如同一故障模式的 25 个重复 bug 会被视为系统性可靠性信号。
主要能力：先做前置检查（确认当前目录为 git 仓库、识别 GitHub 远程仓库、确认 gh CLI 可用与已认证）；若 gh 不可用但接入了 GitHub MCP 服务器，则改用其 issue 列表与读取工具，分析方法一致。随后以节省 token 的方式抓取 issue：先扫描标签识别优先级信号（如 P0、P1、priority:critical、severity:high）与聚焦领域，再抓取开放 issue（优先高优先级，正文截断至 500 字符），并抓取最近关闭的 issue。
分析方式：按主题聚类，从开放 issue 入手，再用最近关闭的 issue 检验主题是否反复出现；仅关闭、无开放 issue 支撑的主题不新建。按根因或系统区域聚类，而非按症状或错误信息。区分人工报告与机器人生成、bug 与增强请求。目标 3-8 个主题。仅在截断正文影响判断时，才对 2-3 条 issue 做完整正文读取。
输出：报告包含仓库、分析数量与日期范围、主题数；每个主题含标题、issue 数、趋势、置信度、来源构成、类型、描述、为何重要、代表 issue 编号与标题，并按 issue 数降序排列。所有数字必须来自实际抓取数据，不得估算或编造。
限制：少于 5 条 issue 时仅返回简短说明与列表；无 issue 时返回未找到。要求不使用脚本、管道或内联代码处理数据，一律用 gh 的 --jq 提取字段，一次抓取一个命令，避免权限弹窗。具体收费、价格与平台支持情况暂未提供。