pr-review-fix

name	pr-review-fix
description	读取当前项目的 PR 审查结果，自动修复中等和严重问题，轻微问题需确认后再决定是否修复

PR 审查结果修复技能

本技能用于读取当前项目关联的 GitHub PR 审查评论，按严重程度分类处理：

• 严重/中等问题：自动分析并修复
• 轻微问题：列出详情后询问用户是否需要修复，非必要不修复

使用前提

• 项目必须是 Git 仓库且已推送到 GitHub
• 本地已安装并登录 gh CLI（GitHub CLI）
• 当前分支有已创建的 PR

执行步骤

1. 获取 PR 信息

运行以下命令获取当前分支关联的 open 状态 PR 编号：

gh pr view --json number,title,url,state,reviewDecision,reviews --jq '.'

获取到 PR 信息后，检查 state 字段：

• 如果 state 为 OPEN → 继续后续步骤
• 如果 state 为 CLOSED 或 MERGED → 提示用户"该 PR 已关闭/合并，无需审查修复"，终止流程
• 如果当前分支没有 PR → 提示用户指定 PR 编号或先创建 PR

如果用户指定了 PR 编号，使用以下命令获取并同样检查状态：

gh pr view {pr_number} --json number,title,url,state,reviewDecision,reviews --jq '.'

2. 获取 PR 审查评论

获取所有 review comments（代码审查中的具体评论）：

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --jq '.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login, created_at: .created_at}'

同时获取 PR 级别的 review（整体审查意见）：

gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --jq '.[] | {id: .id, state: .state, body: .body, user: .user.login}'

如果审查评论中包含 bot 的结构化评论（如 CI 检查工具的输出），也一并解析。

3. 分类问题严重程度

将所有审查意见按以下规则分为三个等级：

🔴 严重 (Critical)：

• 安全漏洞（XSS、注入、路径遍历、未验证输入等）
• 数据丢失风险
• 逻辑错误导致功能完全失效
• 未处理的异常导致应用崩溃
• 关键词：security, vulnerability, crash, data loss, critical, 严重, 安全, 漏洞, 崩溃

🟡 中等 (Medium)：

• 性能问题（内存泄漏、不必要的重渲染、N+1 查询等）
• 错误处理缺失或不完善
• 类型安全问题（any 类型滥用、缺少类型检查）
• 竞态条件或并发问题
• 资源未正确释放
• 关键词：performance, memory leak, error handling, type safety, race condition, 中等, 性能, 错误处理

🟢 轻微 (Minor)：

• 代码风格和格式
• 命名建议
• 注释改进
• 不影响功能的重构建议
• 文档更新
• 关键词：style, naming, comment, refactor, documentation, nit, 轻微, 建议, 风格

如果无法明确判断等级，按以下规则：

• 涉及运行时行为 → 至少中等
• 仅涉及代码可读性 → 轻微

4. 展示分类结果

向用户展示分类后的结果，格式如下：

## PR #XX 审查问题汇总

### 🔴 严重问题 (X 个) — 将自动修复
1. [文件路径:行号] 问题描述
2. ...

### 🟡 中等问题 (X 个) — 将自动修复
1. [文件路径:行号] 问题描述
2. ...

### 🟢 轻微问题 (X 个) — 需确认
1. [文件路径:行号] 问题描述
2. ...

5. 修复严重和中等问题

对每个严重和中等问题：

1. 打开对应文件，定位到指定行
2. 理解审查评论的具体建议
3. 分析上下文，确定最佳修复方案
4. 执行修复
5. 确保修复不引入新问题（检查周围代码的一致性）

修复原则：

• 最小化修改：只修改必要的部分，避免大范围重构
• 保持一致性：修复后的代码风格与项目现有风格保持一致
• 不破坏现有功能：修改后确认相关逻辑仍然正确
• 逐个文件修复：一个文件的所有问题一起修复，减少文件操作次数

6. 处理轻微问题

对每个轻微问题，向用户展示：

🟢 轻微问题 #N: [文件路径:行号]
审查意见: "..."
建议修改: 简要说明修改内容

是否需要修复？(修复 / 跳过)

规则：

• 如果用户说"跳过"或"不修复" → 跳过该问题
• 如果用户说"修复" → 执行修复
• 如果用户说"全部跳过" → 跳过所有剩余轻微问题
• 如果用户说"全部修复" → 修复所有剩余轻微问题
• 默认倾向：轻微问题非必要不修复，如果不确定，建议用户跳过

7. 修复完成后

1. 展示修复汇总：

## 修复汇总

✅ 已修复: X 个严重 + X 个中等 + X 个轻微
⏭️ 已跳过: X 个轻微问题

2. 提示用户下一步操作：
   • 运行测试确认修复无误
   • 提交修复并推送到 PR 分支

注意事项

• 如果同一文件有多个问题，合并为一次编辑操作
• 如果审查评论含糊不清，先理解评论意图再修复
• 如果修复方案有多种选择，选择最安全保守的方案
• 对于已标记为 resolved 的评论，跳过不处理
• 不要修改不在审查范围内的代码