pr-review-fix

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

PR 审查结果修复技能

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

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

使用前提

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

执行步骤

1. 获取 PR 信息

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

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

获取后检查 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 的结构化输出，也一并解析。

3. 分类问题严重程度

按以下规则分类：

🔴 严重 (Critical)：

• 安全漏洞
• 数据丢失风险
• 逻辑错误导致功能完全失效
• 未处理异常导致应用崩溃

🟡 中等 (Medium)：

• 性能问题
• 错误处理缺失或不完善
• 类型安全问题
• 竞态条件或并发问题
• 违反当前仓库的强制分层与目录规则

🟢 轻微 (Minor)：

• 代码风格和格式
• 命名建议
• 注释改进
• 不影响功能的重构建议
• 文档更新

如果无法明确判断等级：

• 涉及运行时行为，至少按中等处理
• 仅涉及可读性，按轻微处理

4. 展示分类结果

向用户展示：

## PR #XX 审查问题汇总

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

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

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

5. 修复严重和中等问题

对每个严重和中等问题：

1. 打开对应文件，定位到指定行
2. 理解审查评论意图
3. 结合当前仓库规则分析最安全的修复方案
4. 执行修复
5. 确保修复不引入新的边界违规或无关改动

修复原则：

• 最小化修改：只改必要部分
• 保持一致性：与项目现有风格和目录职责一致
• 不破坏现有功能：重点关注相关链路是否被误伤
• 同文件合并修复：减少重复编辑

6. 处理轻微问题

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

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

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

规则：

• 用户说“跳过”或“不修复”，则跳过
• 用户说“修复”，则执行修复
• 用户说“全部跳过”，则跳过所有剩余轻微问题
• 用户说“全部修复”，则修复所有剩余轻微问题
• 默认倾向：轻微问题非必要不修复

7. 修复完成后

展示修复汇总：

## 修复汇总

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

如需验证，优先使用当前仓库允许的现有命令，例如：

• npm run lint
• npm run type-check
• 必要时 npm run build-only

注意事项

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