| name | pr-review |
| description | 处理 PR review 和 code review 评论：获取或解析 review 内容、分类优先级、 判断哪些意见需要修复、哪些应跳过，并协助逐条修改代码或组织回复。当用户提供 PR URL、 粘贴 reviewer 意见，或提到 "review message"、"review 意见"、"PR 评论"、 "处理 review"、"review 反馈"、"帮我处理这些 review 意见"时触发。
|
PR Review 处理技能
帮助用户系统化地处理 PR review 评论：分类优先级、过滤低价值意见、深入理解问题本质后再修改代码。
核心原则
- 先理解，后动手 — 不要看到一条评论就立刻改代码。先通读所有评论，理解 reviewer 的整体关注点，再制定修改方案。
- 治本不治标 — 如果 reviewer 指出了一个症状，先找到根因。不要只修表面。
- 文档/注释的语言措辞修改优先级极低 — 除非存在事实性错误或严重误导，否则跳过纯粹的文字润色建议。
- 尊重但不盲从 — 合理的意见要认真处理，不合理的意见要给出跳过理由。
阶段一：获取 Review 评论
根据用户提供的输入方式获取评论内容：
方式 A：用户提供 PR URL
- 使用
gh 命令获取 PR 详情和 review comments：
gh pr view <PR_NUMBER> --json number,title,body,reviews,comments
gh api --paginate repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments
gh api --paginate repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews
- 解析所有 review 评论，包括行内评论和总体评论
- 关联每条评论到对应的文件和代码行
方式 B：用户直接粘贴评论内容
- 接收用户粘贴的评论文本
- 如果格式不清晰，请用户补充：涉及哪个文件、哪段代码
获取完毕后，列出所有评论的摘要清单，让用户确认没有遗漏。
阶段二：分类评估
将每条 review 评论分为四个优先级：
| 优先级 | 标签 | 含义 | 处理方式 |
|---|
| P0 | 必须修复 | 逻辑错误、安全漏洞、数据丢失风险、API 契约违反 | 立即修复 |
| P1 | 建议修复 | 性能隐患、可维护性问题、不符合项目规范、潜在 bug | 应当修复，除非有充分理由不改 |
| P2 | 可以改进 | 代码风格偏好、更优雅的写法、微小的命名改进 | 与用户讨论后决定 |
| SKIP | 跳过 | 文档/注释的纯语言润色、主观偏好无明显优劣、改动成本远大于收益 | 不处理，说明理由 |
输出格式：
### Review 评论分类结果
| # | 评论摘要 | 文件 | 优先级 | 理由 |
|---|----------|------|--------|------|
| 1 | 缺少空指针检查 | src/api/user.ts:42 | P0 必须修复 | 生产环境会导致崩溃 |
| 2 | 建议用 Map 替代 Object | src/utils/cache.ts:15 | P1 建议修复 | 性能更好且语义更清晰 |
| 3 | 变量名 `d` 改为 `data` | src/api/user.ts:50 | P2 可以改进 | 可读性微小提升 |
| 4 | 注释中 "recieve" 拼写错误 | src/api/user.ts:38 | SKIP | 纯注释文字修改，优先级极低 |
对每个 SKIP 项，必须给出一句话理由。
展示分类结果后，等待用户确认或调整分类。用户可能会：
- 把某个 SKIP 提升为 P1（"这个还是改一下吧"）
- 把某个 P1 降为 SKIP（"这个不用管"）
- 补充额外上下文
阶段三：深入分析
用户确认分类后，对所有 P0 和 P1 项进行深入分析。不要急于修改代码。
对每一条需要处理的评论：
- 阅读完整上下文 — 不只看评论指向的那一行，要读整个函数、整个模块，理解代码的意图和设计
- 追溯根因 — 如果 reviewer 说"这里有 bug"，先搞清楚 bug 的根本原因是什么。可能问题不在 reviewer 指出的那一行，而在上游
- 评估影响范围 — 修改这里会影响哪些其他地方？有没有类似的问题在其他位置也存在？
- 设计修复方案 — 确定最佳的修改方式，而不是最小的修改方式
输出修复方案：
### 修复方案
#### #1 缺少空指针检查 (P0)
**问题根因：** `fetchUser` 返回值在整个调用链中都没有做空值处理，
不只是 reviewer 指出的第 42 行，第 67 行和第 89 行也有同样的问题。
**修复方案：** 在 `fetchUser` 函数返回处统一处理，返回 Result 类型，
迫使所有调用方显式处理错误情况。
**影响范围：** 需要修改 3 个调用方（user.ts、profile.ts、admin.ts）
展示修复方案后，等待用户确认。
阶段四：执行修复
用户确认方案后，按优先级顺序执行修改：
- 先处理所有 P0 项
- 再处理所有 P1 项
- 如果用户同意，处理 P2 项
- 对所有 SKIP 项，在 PR 中回复 reviewer 说明不修改的理由
回复 SKIP 项很重要： AI reviewer（如 Copilot）不会记住之前的上下文，如果不回复说明理由，它会在后续 review 中重复提出同样的问题。对每个 SKIP 项，使用 gh 命令回复对应的 review comment，简要说明为什么不采纳。
gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments/<COMMENT_ID>/replies \
-f body="<回复内容>"
每修改一处：
- 确保修改符合项目现有的代码风格和规范
- 如果修改涉及多个文件，保持一致性
- 运行项目的测试和类型检查（如果有的话）
不要做的事：
- 不要顺手修改 reviewer 没提到的东西（除非是修复根因时必须一起改的）
- 不要重构不相关的代码
- 不要修改代码风格（除非这正是 review 意见要求的）
- 不要仅仅为了让 diff 好看而调整无关的格式
阶段五：总结报告
所有修改完成后，生成处理总结：
### PR Review 处理总结
**已处理：**
| # | 评论 | 优先级 | 处理方式 | 修改文件 |
|---|------|--------|----------|----------|
| 1 | 缺少空指针检查 | P0 | 重构为 Result 类型 | user.ts, profile.ts, admin.ts |
| 2 | 用 Map 替代 Object | P1 | 已替换 | cache.ts |
**已跳过：**
| # | 评论 | 原因 |
|---|------|------|
| 4 | 注释拼写错误 | 纯注释文字修改，不影响代码功能，优先级极低 |
**建议回复 reviewer：**
> [为用户草拟一段简短的回复，说明哪些已修改、哪些未修改及原因，语气专业友善]
注意事项
- 评论很多时不要一次性全部处理 — 先分类、确认，再分批处理
- 遇到有争议的评论 — 向用户说明双方观点，让用户决定
- 如果 reviewer 的建议会引入新的问题 — 明确指出，建议与 reviewer 讨论
- 始终用中文与用户交互，但代码和 commit message 保持项目原有语言；若仓库未明确约定提交信息语言，AI 生成或修改的 commit message 默认使用中文
