用途
triage-github 用于对当前仓库的 GitHub 开放工作做一次优先级梳理。它面向的场景是：用户希望获得一个整体视图，判断哪些 PR 应优先合并或评审、哪些 Issue 应优先修复、哪些 Discussion 需要维护者参与。典型触发语包括“triage the backlog”“what should I look at first”“prioritize open PRs and issues”“sweep open work”“triage discussions”。
它不适用于单条目审查（直接查看即可），也不适用于需要持续自动化的场景（应改用 /schedule）。
主要能力
- 并行梳理：最多启动 100 个子代理，每个条目一个，覆盖 PR、Issue 和 Discussion。
- 数据采集：通过 gh CLI 和 GraphQL 获取 PR、Issue、Discussion 的元数据、CI 状态、评审状态、标签、评论、反应、关联关系等。
- 优先级评定：按 P0 至 P3 分级，并给出推荐动作（如 merge、review、fix、answer、convert-to-issue 等）。
- 关联与去重：识别 PR 关闭的 Issue、Issue 关联的 PR、Discussion 关联的 Issue/PR，并按 PR > Issue > Discussion 的层级折叠，避免重复呈现。
- 快照与差异：将机器可读快照保存到本地目录，与上一次运行对比，输出新增、已解决、升级、降级、反复高优先级等变化。
- 报告生成：输出人类可读的 Markdown 报告，按优先级和层级组织。
使用方式
前置条件：
- gh CLI 已认证（gh auth status）。若未认证，应停止并请用户认证，不要自动修复认证。
- 在 git 仓库内运行，且 origin 指向要梳理的 GitHub 仓库。可用 gh repo view --json nameWithOwner,hasDiscussionsEnabled 确认。
- 若 hasDiscussionsEnabled 为 false，则完全跳过 Discussion 部分，并在报告中注明 Discussion 已禁用。
流程概要：
- 并行获取开放工作：使用 gh pr list、gh issue list 以及 GraphQL 查询获取 Discussion。若总数超过 100，需告知用户各分类数量，并询问是截取最近更新的 100 条还是分批处理。
- 决定并行拆分：若总数不超过 100，则每个条目一个代理；否则优先 PR，其次按最近更新排序的 Issue，再是 Discussion，直到 100 上限，并在报告中注明被跳过的条目。
- 扇出子代理：在单条消息中通过多个 Agent 工具调用派发，使用 subagent_type: "general-purpose" 和 run_in_background: false，以同步获取结果。每个代理返回单行 JSON 对象。
- 聚合：收集所有 JSON，构建关联/去重映射，排序，并计算与上一次快照的差异。
- 写入快照，再写报告：快照保存到本地数据目录（.agent/triage/ 或 .triage/），报告保存为 TRIAGE_REPORT.md 或 .agent/triage/TRIAGE_REPORT-YYYY-MM-DD.md。
适用场景
- 维护者需要快速了解仓库中所有开放工作的优先级。
- 需要判断哪些 PR 可以立即合并、哪些需要评审、哪些应关闭。
- 需要识别高优先级 Issue 和需要维护者回应的 Discussion。
- 需要跟踪多次运行之间的变化，发现被忽视的反复高优先级条目。
限制
- 依赖已认证的 gh CLI，且必须在指向目标仓库的 git 仓库内运行。
- 单次最多 100 个子代理，超出需截取或分批。
- 不适用于单条目审查或持续自动化。
- 若仓库未启用 Discussion，则跳过该部分。
- 快照为本地工作数据，不应提交到仓库。
- 若上一次快照缺失或无法解析，则跳过差异部分，不进行猜测。
- 具体收费、价格、平台支持等信息暂未提供。