review-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review PR Skill

PR审查技能

Review the current pull request and write the output to

review.json

审查当前拉取请求（PR）并将输出写入

review.json

。

Context

上下文

The working directory is the PR branch checkout.
The workflow provides an annotated diff in
```
pr_diff.txt
```
.
The workflow provides the PR description in
```
pr_description.txt
```
.
Focus on files and lines changed by this PR.
Do not post comments or reviews to GitHub directly.

工作目录为PR分支的检出目录。
工作流在
```
pr_diff.txt
```
中提供带注释的差异文件。
工作流在
```
pr_description.txt
```
中提供PR描述。
重点关注此PR修改的文件和代码行。
请勿直接在GitHub上发布评论或审查意见。

Review Scope

审查范围

Prioritize correctness, security, error handling, and meaningful performance issues.
Include style or nit comments only when you can provide a concrete suggestion block.
If a concern involves untouched code, mention it in the summary instead of an inline comment.
Do not suggest adding test cases that only vary constructor inputs or struct fields when the existing test already covers the meaningful behavior. Only suggest new tests when they exercise a distinct code path or edge case.
When a PR is clearly a V0 or initial implementation, frame robustness suggestions (timeouts, retries, lifecycle management) as optional future work rather than blocking concerns, unless they risk correctness, security, or data loss.

优先检查正确性、安全性、错误处理以及影响显著的性能问题。
仅当能提供具体的建议代码块时，才添加风格或细微调整（nit）类评论。
如果问题涉及未修改的代码，请在摘要中提及，而非添加行内评论。
若现有测试已覆盖有意义的行为，请勿建议添加仅改变构造函数输入或结构体字段的测试用例。仅当新测试能覆盖独特的代码路径或边缘情况时，才建议添加。
当PR明显是V0版本或初始实现时，将健壮性建议（超时、重试、生命周期管理）列为可选的未来工作，而非阻塞性问题，除非这些问题可能影响正确性、安全性或导致数据丢失。

Diff Line Annotations

差异行注释规则

The diff file uses these prefixes:

```
[OLD:n]
```
for deleted lines on the old side. Use
```
"LEFT"
```
.
```
[NEW:n]
```
for added lines on the new side. Use
```
"RIGHT"
```
.
```
[OLD:n,NEW:m]
```
for unchanged context. Use
```
"RIGHT"
```
with line
```
m
```
.

差异文件使用以下前缀：

```
[OLD:n]
```
代表旧版本中删除的行，对应使用
```
"LEFT"
```
。
```
[NEW:n]
```
代表新版本中添加的行，对应使用
```
"RIGHT"
```
。
```
[OLD:n,NEW:m]
```
代表未修改的上下文，对应使用
```
"RIGHT"
```
并指定行号
```
m
```
。

Comment Requirements

评论要求

Every comment body must start with one of these labels:

```
🚨 [CRITICAL]
```
for bugs, security issues, crashes, or data loss.
```
⚠️ [IMPORTANT]
```
for logic problems, edge cases, or missing error handling.
```
💡 [SUGGESTION]
```
for worthwhile improvements or better patterns.
```
🧹 [NIT]
```
for cleanup only when the comment includes a suggestion block.

Write comments with these constraints:

Be concise, direct, and actionable.
Do not add compliments or hedging.
Prefer single-line comments.
Keep ranges to at most 10 lines.
Restrict inline comments to valid changed lines in this PR.

每条评论正文必须以以下标签之一开头：

```
🚨 [CRITICAL]
```
：用于标记 bug、安全问题、崩溃或数据丢失相关问题。
```
⚠️ [IMPORTANT]
```
：用于标记逻辑问题、边缘情况或缺失的错误处理。
```
💡 [SUGGESTION]
```
：用于标记有价值的改进或更优实现模式。
```
🧹 [NIT]
```
：仅当评论包含建议代码块时，才用于标记代码清理类建议。

撰写评论需遵循以下约束：

简洁、直接且可执行。
请勿添加赞美或模棱两可的表述。
优先使用单行评论。
评论覆盖的代码范围最多不超过10行。
行内评论仅针对此PR中有效的修改行。

Suggestion Blocks

建议代码块

When proposing a code change, use:

suggestion

<replacement code here>

Rules:

Match the exact indentation of the original file.
Include only replacement code.
For multi-line suggestions, set
```
start_line
```
to the first line and
```
line
```
to the last line.

当提议代码修改时，请使用：

suggestion

<replacement code here>

规则：

与原文件的缩进完全匹配。
仅包含替换代码。
对于多行建议，将
```
start_line
```
设为起始行，
```
line
```
设为结束行。

Output Format

输出格式

Create

review.json

with this shape:

json

{
  "summary": "## Overview\n...\n\n## Concerns\n- ...\n\n## Verdict\nFound: 1 critical, 2 important, 3 suggestions\n\n**Request changes**",
  "comments": [
    {
      "path": "path/to/file",
      "line": 42,
      "side": "RIGHT",
      "start_line": 40,
      "body": "⚠️ [IMPORTANT] Short explanation\n\n```suggestion\nreplacement\n```"
    }
  ]
}

Field rules:

```
path
```
must be relative to the repository root.
```
line
```
is required and must target the correct side.
```
start_line
```
is optional and only for multi-line ranges.
```
side
```
must be
```
"LEFT"
```
or
```
"RIGHT"
```
.

创建

review.json

，格式如下：

json

{
  "summary": "## 概述\n...\n\n## 问题\n- ...\n\n## 结论\n发现：1个严重问题，2个重要问题，3个建议\n\n**要求修改**",
  "comments": [
    {
      "path": "path/to/file",
      "line": 42,
      "side": "RIGHT",
      "start_line": 40,
      "body": "⚠️ [IMPORTANT] 简短说明\n\n```suggestion\n替换代码\n```"
    }
  ]
}

字段规则：

```
path
```
必须是相对于仓库根目录的路径。
```
line
```
为必填项，必须指向正确的侧（LEFT/RIGHT）。
```
start_line
```
为可选项，仅用于多行范围。
```
side
```
必须为
```
"LEFT"
```
或
```
"RIGHT"
```
。

Summary Requirements

摘要要求

The

summary

must include:

A high-level overview of the PR.
Important concerns and any untouched-code concerns that could not be commented inline.

Issue counts in the format

Found: X critical, Y important, Z suggestions

A final recommendation of
```
Approve
```
,
```
Approve with nits
```
, or
```
Request changes
```
.

summary

必须包含：

PR的高层概述。
重要问题以及无法在行内评论的未修改代码相关问题。

问题统计，格式为

发现：X个严重问题，Y个重要问题，Z个建议

。

最终建议：

批准

、

批准（含细微调整建议）

或

要求修改

。

Final Checks

最终检查

Before finishing:

Validate
```
review.json
```
with
```
jq
```
.
Fix invalid JSON if validation fails.
Confirm line numbers match the annotated diff.
Do not run
```
gh pr review
```
,
```
gh pr comment
```
,
```
gh api
```
, or any other command that posts to GitHub.

Your only output is the final

review.json

完成前请执行：

使用
```
jq
```
验证
```
review.json
```
的有效性。
若验证失败，修复无效的JSON。
确认行号与带注释的差异文件匹配。
请勿运行
```
gh pr review
```
、
```
gh pr comment
```
、
```
gh api
```
或任何其他会发布到GitHub的命令。

你的唯一输出是最终的

review.json

。