fix-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix PR Review Comments

修复PR评审意见

Fetch review comments from a GitHub PR and apply fixes to the local codebase.

从GitHub PR中获取评审意见，并对本地代码库应用修复。

Current PR context

当前PR上下文

gh pr view --json number,url,headRefName 2>/dev/null || echo "NO_PR_FOUND"

gh pr view --json number,url,headRefName 2>/dev/null || echo "NO_PR_FOUND"

Step 1: Identify the PR

步骤1：确定PR编号

If the user provided a PR number as

$ARGUMENTS

, use that instead of the auto-detected PR above.

If no PR is found (output shows NO_PR_FOUND and no argument was given), stop and tell the user:

There is no open PR for the current branch
They need to either push and create a PR first, or provide a PR number

如果用户通过

$ARGUMENTS

提供了PR编号，则使用该编号，而非上面自动检测到的PR。

如果未找到PR（输出显示NO_PR_FOUND且未提供参数），则停止操作并告知用户：

当前分支没有打开的PR
他们需要先推送代码并创建PR，或者提供一个PR编号

Step 2: Verify gh CLI is available

步骤2：验证gh CLI是否可用

gh --version 2>/dev/null || echo "GH_NOT_FOUND"

gh

is not installed, stop and tell the user to install it: https://cli.github.com

gh --version 2>/dev/null || echo "GH_NOT_FOUND"

如果未安装

gh

，则停止操作并告知用户安装：https://cli.github.com

Step 3: Fetch review comments

步骤3：获取评审意见

Fetch all inline review comments on the PR:

gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate

Each comment object has these relevant fields:

```
path
```
— file path
```
line
```
(or
```
original_line
```
) — line number in the new file
```
body
```
— the comment text
```
diff_hunk
```
— surrounding diff context
```
user.login
```
— who posted it

获取PR上所有的行内评审意见：

gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate

每个评论对象包含以下相关字段：

```
path
```
— 文件路径
```
line
```
（或
```
original_line
```
）— 新文件中的行号
```
body
```
— 评论文本
```
diff_hunk
```
— 周围的diff上下文
```
user.login
```
— 评论发布者

Step 4: Parse and classify comments

步骤4：解析并分类评论

Bot review comments (structured severity markers)

机器人评审意见（结构化严重程度标记）

Look for severity markers in the comment

body

```
**🔴 Critical**
```
— Must fix. Production crash, security, data loss.
```
**🟠 High**
```
— Must fix. Significant bugs, logical flaws.
```
**🟡 Medium**
```
— Should fix. Tech debt, best practice deviation.
```
**🟢 Low**
```
— Optional. Nitpick, stylistic.
```
**✨ Praise**
```
— Skip. Positive feedback.

Also extract from the body:

Category (e.g.
```
**✅ Correctness**
```
,
```
**🛡️ Security**
```
) — appears after severity on the first line
Comment text — the main feedback paragraph
Why it matters — appears in a blockquote starting with
```
💡 **Why it matters:**
```
Code suggestion — appears in a
```
```suggestion
```
fenced block (GitHub's suggested change format)

在评论

body

中查找严重程度标记：

```
**🔴 Critical**
```
— 必须修复。生产环境崩溃、安全问题、数据丢失。
```
**🟠 High**
```
— 必须修复。严重bug、逻辑缺陷。
```
**🟡 Medium**
```
— 应该修复。技术债务、偏离最佳实践。
```
**🟢 Low**
```
— 可选修复。细节建议、风格问题。
```
**✨ Praise**
```
— 跳过。正面反馈。

同时从正文中提取：

类别（例如
```
**✅ Correctness**
```
、
```
**🛡️ Security**
```
）— 出现在第一行的严重程度标记之后
评论文本 — 主要反馈段落
重要性说明 — 出现在以
```
💡 **Why it matters:**
```
开头的块引用中
代码建议 — 出现在
```
```suggestion
```
代码块中（GitHub的建议修改格式）

Human review comments (no severity markers)

人工评审意见（无严重程度标记）

If a comment has no structured severity markers, classify it as a human comment. Do NOT auto-fix these — list them separately for the user to address manually.

如果评论没有结构化严重程度标记，则归类为人工评论。不要自动修复这些评论——单独列出供用户手动处理。

Fallback: no bot comments found

回退方案：未找到机器人评论

If there are zero comments with severity markers, treat ALL comments as potentially actionable:

Show them to the user in a summary table
Ask which ones to address
Only proceed with explicit user confirmation

如果没有带有严重程度标记的评论，则将所有评论视为潜在可处理项：

以汇总表格形式展示给用户
询问用户要处理哪些
仅在用户明确确认后再继续

Step 5: Apply fixes

步骤5：应用修复

Sort bot comments by severity: Critical > High > Medium > Low.

For each comment (Critical, High, and Medium severity):

Read the file at
```
path
```
Understand the issue described in the comment
If a
```
suggestion
```
block exists, use it as a strong hint — but verify it makes sense in context before applying blindly
Show the proposed fix to the user and ask for explicit confirmation before applying it.
If a comment is unclear or the fix would require broader refactoring beyond the scope, note it and skip

For Low severity: skip unless trivially fixable (one-line change).

For Praise: skip entirely.

按严重程度排序机器人评论：Critical > High > Medium > Low。

对于每条评论（Critical、High和Medium严重程度）：

读取
```
path
```
对应的文件
理解评论中描述的问题
如果存在
```
suggestion
```
代码块，将其作为重要参考——但在盲目应用前需验证其在上下文中是否合理
向用户展示拟议的修复方案，并在应用前请求明确确认
如果评论不明确，或修复需要超出范围的广泛重构，则记录并跳过该评论

对于Low严重程度：除非是可轻松修复的（单行修改），否则跳过。

对于Praise：完全跳过。

Step 6: Summary

步骤6：汇总

After applying fixes, provide a summary table:

Severity	File	Line	Status	Notes
🔴 Critical	path/to/file.ts	42	✅ Fixed	Brief description
🟠 High	path/to/other.ts	17	⏭️ Skipped	Requires broader refactor

Then list:

Skipped comments with reasoning
Human feedback (non-bot comments) that the user should address manually

应用修复后，提供汇总表格：

严重程度	文件	行号	状态	备注
🔴 Critical	path/to/file.ts	42	✅ 已修复	简要描述
🟠 High	path/to/other.ts	17	⏭️ 已跳过	需要广泛重构

然后列出：

已跳过的评论及原因
人工反馈（非机器人评论），供用户手动处理

Rules

规则

Do NOT blindly apply suggestions without reading the surrounding code
Do NOT modify files that weren't mentioned in review comments
If there are no review comments on the PR, tell the user and stop
Human review comments should be shown to the user but not auto-fixed — list them separately as "Human feedback to address"
If
```
gh
```
CLI is not authenticated, tell the user to run
```
gh auth login
```

不要盲目应用建议，需先阅读周边代码
不要修改评审意见中未提及的文件
如果PR上没有评审意见，告知用户并停止操作
人工评审意见应展示给用户，但不要自动修复——单独列为“需处理的人工反馈”
如果
```
gh
```
CLI未认证，告知用户运行
```
gh auth login
```