| name | mcp_triage |
| description | 批量处理 GitHub 上的 open issues 和 pull requests。逐一分析、评审、修复，所有破坏性操作（merge、close、comment）均需用户确认。当用户说"处理 issue"、"处理 PR"、"triage"时使用。 |
处理 Issues 和 Pull Requests
批量处理当前仓库的所有 open issues 和 pull requests。
前置条件
- 已安装
gh CLI 并已登录（gh auth status）
- 当前目录是目标仓库的 git 工作区
处理流程
Step 1: 获取概览
获取所有 open issues 和 PRs：
gh issue list --state open --json number,title,author,labels,createdAt,body --limit 50
gh pr list --state open --json number,title,author,labels,createdAt,isDraft,headRefName,baseRefName --limit 50
输出汇总表格，让用户了解当前工作量。
Step 2: 排序
按以下优先级处理：
Issues：
- 带
bug 标签的 issue
- 带
security 标签的 issue
- 其他 issue（按创建时间从旧到新）
Pull Requests：
- dependabot PR — patch/minor 升级（最简单，快速处理）
- dependabot PR — major 升级
- 社区贡献的 PR（按创建时间从旧到新）
Step 3: 逐一处理 Issue
对每个 issue 依次执行以下步骤：
3a. 展示信息
gh issue view <number> --json title,body,author,labels,comments
展示 issue 标题、作者、创建时间、内容摘要。
3b. 分析根因
- 在代码库中搜索 issue 中提到的关键字（函数名、参数名、错误信息）
- 追踪相关代码路径
- 如果 issue 涉及 API 行为，用
.env 中的 token 实际调用验证
3c. 给出结论并询问用户
给出以下三类结论之一，必须等用户确认后才执行操作：
| 结论 | 操作 | 需要确认 |
|---|
| 可修复 | 提出修复方案，修复代码 | 是 — 确认方案后修复 |
| 需要更多信息 | 草拟回复 comment 请求补充信息 | 是 — 确认内容后发送 |
| Won't fix / 非 bug | 草拟回复并建议关闭 | 是 — 确认后关闭 |
修复 issue 后，不要自动发版。代码修改完成后告知用户，由用户决定是否发版。
Step 4: 逐一处理 Pull Request
对每个 PR 依次执行以下步骤：
4a. 展示信息
gh pr view <number> --json title,body,author,labels,files,additions,deletions,commits
gh pr diff <number>
展示 PR 标题、作者、变更文件数、增删行数。
4b. 代码评审
阅读 diff 内容，按以下维度评审：
- TypeScript 类型安全：类型是否正确，是否有
any 滥用
- Zod schema 正确性：新增字段的类型、optional/required 是否与 API 一致
- API 兼容性：tool name 或 inputSchema 是否有 breaking change
- 安全性：有无凭证泄露、注入风险
- 依赖升级（dependabot PR）：查看 changelog 确认无 breaking change
4c. 给出结论并询问用户
| 结论 | 操作 | 需要确认 |
|---|
| 建议合并 | gh pr review --approve + gh pr merge --squash | 是 |
| 需要修改 | 草拟 review comment 指出问题 | 是 — 确认内容后发送 |
| 建议关闭 | 说明理由，草拟关闭 comment | 是 — 确认后关闭 |
对于 dependabot 的 patch/minor PR，可以批量展示评审结果，询问用户是否一次性全部合并。
Step 5: 汇总报告
所有 issue 和 PR 处理完毕后，输出汇总：
处理完成
Issues:
- #74: 已修复并关闭
- #65: 已回复，等待用户反馈
Pull Requests:
- #73: 已合并 (qs 6.15.0 → 6.15.2)
- #69: 已合并 (fast-uri 3.1.0 → 3.1.2)
- #27: 已发送 review comment
待发版: 有 N 个修复待发版（需要手动执行发版）
核心原则
- 所有破坏性操作必须等用户确认 — merge、close、comment 都需要明确同意
- 不自动发版 — 修复代码后告知用户，由用户决定何时发版
- 使用
gh CLI — 所有 GitHub 交互通过 gh 命令完成
- 逐一处理 — 不要跳过任何 issue 或 PR，按优先级依次处理
