arinhub-submit-pr-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Submit PR Review

提交PR评审

Submit a structured code review with line-specific comments to a GitHub pull request. Identifies issues in the current chat session, checks for duplicate comments, and submits the review only if new issues are found.

向GitHub拉取请求提交带有特定代码行评论的结构化代码评审。识别当前聊天会话中的问题，检查重复评论，仅在发现新问题时提交评审。

Input

输入

PR number or URL (required): The pull request identifier. Accepts:
- Number:
```
123
```
- Hash-prefixed:
```
#123
```
- Full URL:
```
https://github.com/owner/repo/pull/123
```

PR编号或URL（必填）：拉取请求的标识符。支持：
- 编号：
```
123
```
- 带#前缀：
```
#123
```
- 完整URL：
```
https://github.com/owner/repo/pull/123
```

Procedure

流程

1. Resolve PR Identifier

1. 解析PR标识符

Extract the PR number from the user input. Strip any

prefix or parse the number from a URL.

PR_NUMBER=<extracted number>

从用户输入中提取PR编号。去除任何

前缀，或从URL中解析编号。

PR_NUMBER=<extracted number>

2. Fetch PR Metadata

2. 获取PR元数据

Gather PR details:

bash

gh pr view $PR_NUMBER --json number,title,body,baseRefName,headRefName,files,url

收集PR详情：

bash

gh pr view $PR_NUMBER --json number,title,body,baseRefName,headRefName,files,url

3. Fetch Existing Review Comments

3. 获取现有评审评论

Retrieve all existing review comments to prevent duplication:

bash

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

Also fetch top-level review bodies:

bash

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

检索所有现有评审评论以避免重复：

bash

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

同时获取顶层评审内容：

bash

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

4. Get Issue List

4. 获取问题列表

Get a list of issues from one of these sources (in priority order):

Log file: If a log file path is provided (e.g., from
```
arinhub-review-pr
```
orchestrator), read the file and extract all issues from the
```
## Issues
```
section.
Current chat session: If no log file is specified, collect issues identified during the code review in the current chat session.

For each issue found, record:

```
path
```
: The relative file path
```
line
```
: The specific line number in the new version of the file (must be within the diff hunk). For multi-line issues, this is the last line of the range.
```
start_line
```
(optional): The first line of a multi-line range. Only set when the issue spans more than one line.
```
body
```
: A concise, actionable comment explaining the issue
```
suggestion
```
(optional): The replacement code that should replace the line(s) from
```
start_line
```
(or
```
line
```
) through
```
line
```
. Include this whenever you can propose a concrete fix. The suggestion content is the exact code that will replace the selected lines -- do not include
```
```suggestion
```
fences here, they are added automatically in Step 7.

从以下来源之一获取问题列表（按优先级排序）：

日志文件：如果提供了日志文件路径（例如来自
```
arinhub-review-pr
```
编排器），读取文件并从
```
## Issues
```
部分提取所有问题。
当前聊天会话：如果未指定日志文件，收集当前聊天会话中代码评审识别出的问题。

对于每个找到的问题，记录：

```
path
```
：相对文件路径
```
line
```
：文件新版本中的具体行号（必须位于差异块内）。对于多行问题，这是范围的最后一行。
```
start_line
```
（可选）：多行范围的第一行。仅当问题跨越多行时设置。
```
body
```
：简洁、可执行的问题说明
```
suggestion
```
（可选）：应替换从
```
start_line
```
（或
```
line
```
）到
```
line
```
的代码行的替代代码。只要能提出具体修复方案就包含此项。建议内容是将替换所选代码行的精确代码——此处不要包含
```
```suggestion
```
围栏，它们会在步骤7中自动添加。

5. Deduplicate Comments

5. 去重评论

For each issue identified in Step 4, compare against existing comments from Step 3:

Skip if an existing comment on the same
```
path
```
and
```
line
```
(or nearby range +/- 3 lines) already addresses the same concern
Skip if the issue is already mentioned in any top-level review body
Use semantic comparison, not exact string matching -- if the existing comment covers the same problem, even with different wording, skip the new comment

对于步骤4中识别的每个问题，与步骤3中的现有评论进行比较：

如果同一
```
path
```
和
```
line
```
（或附近±3行范围）的现有评论已解决相同问题，则跳过
如果问题已在任何顶层评审内容中提及，则跳过
使用语义比较，而非精确字符串匹配——如果现有评论涵盖相同问题，即使措辞不同，也跳过新评论

6. Decision Gate

6. 决策节点

If no new issues remain after deduplication: Do not submit a review. Inform the user that no new issues were found.
If new issues exist: Proceed to Step 7.

去重后无新问题：不要提交评审。告知用户未发现新问题。
存在新问题：继续步骤7。

7. Submit the Review

7. 提交评审

Use the GitHub API to submit a review with inline comments:

bash

gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/reviews \
  --method POST \
  --input - <<'EOF'
{
  "event": "APPROVE or COMMENT",
  "body": "<two-sentence-summary>",
  "comments": [
    {
      "path": "<file-path>",
      "line": <line-number>,
      "side": "RIGHT",
      "body": "<comment-text>\n\n```suggestion\n<replacement-code>\n```"
    }
  ]
}
EOF

For multi-line suggestions, add

start_line

and

start_side

json

{
  "path": "<file-path>",
  "start_line": <first-line>,
  "line": <last-line>,
  "start_side": "RIGHT",
  "side": "RIGHT",
  "body": "<comment-text>\n\n```suggestion\n<replacement-code>\n```"
}

If a comment has no suggestion (pure observation), omit the

```suggestion ```

block from the body and the

side

field.

Rules for the review body:

Write exactly 2 sentences summarizing what was reviewed and key observations
If no critical issues are found, start with
```
LGTM
```
and use
```
APPROVE
```
as the event type
If critical issues are found, start with a brief statement of the main concern and use
```
COMMENT
```
as the event type
Do not use emojis anywhere in the body or comments

Rules for individual comments:

Keep each comment concise and actionable
Explain the "why" not just the "what"
Prefer suggested changes over plain comments whenever a concrete fix can be proposed -- use the
```
```suggestion ```
```
block format
The explanation text goes before the suggestion block in the
```
body
```
Do not use emojis in any comment text
Each comment
```
line
```
must fall within a diff hunk for the given
```
path
```
```
side
```
must be
```
"RIGHT"
```
(the new version of the file) for comments with suggestions

使用GitHub API提交带有行内评论的评审：

bash

gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/reviews \
  --method POST \
  --input - <<'EOF'
{
  "event": "APPROVE or COMMENT",
  "body": "<two-sentence-summary>",
  "comments": [
    {
      "path": "<file-path>",
      "line": <line-number>,
      "side": "RIGHT",
      "body": "<comment-text>\n\n```suggestion\n<replacement-code>\n```"
    }
  ]
}
EOF

对于多行建议，添加

start_line

和

start_side

：

json

{
  "path": "<file-path>",
  "start_line": <first-line>,
  "line": <last-line>,
  "start_side": "RIGHT",
  "side": "RIGHT",
  "body": "<comment-text>\n\n```suggestion\n<replacement-code>\n```"
}

如果评论无建议（仅观察），则从body中省略

```suggestion ```

块和

side

字段。

评审内容规则：

撰写恰好两句话总结评审内容和关键观察结果
如果未发现严重问题，以
```
LGTM
```
开头，并使用
```
APPROVE
```
作为事件类型
如果发现严重问题，以简要说明主要问题开头，并使用
```
COMMENT
```
作为事件类型
内容和评论中不得使用表情符号

单个评论规则：

每个评论保持简洁且可执行
解释「原因」而非仅说明「内容」
优先使用建议更改而非普通评论，只要能提出具体修复方案——使用
```
```suggestion ```
```
块格式
说明文本放在
```
body
```
中的建议块之前
任何评论文本中不得使用表情符号
每个评论的
```
line
```
必须属于给定
```
path
```
的差异块内
带建议的评论的
```
side
```
必须为
```
"RIGHT"
```
（文件的新版本）

8. Report Result

8. 报告结果

After submission, confirm to the user:

Number of review comments submitted
The PR URL for reference
Brief list of issues flagged

If no review was submitted (Step 6), explain that no new issues were found beyond existing review comments.

提交后，向用户确认：

提交的评审评论数量
供参考的PR URL
标记的问题简要列表

如果未提交评审（步骤6），解释未发现超出现有评审评论的新问题。

9. Extract PR Coverage

9. 提取PR覆盖率

Look for a PR Coverage section in the same source used in Step 4:

Log file: If a log file was used, look for a
```
## PR Coverage
```
or
```
## Coverage
```
section and extract its full content.
Current chat session: If no log file was used, look for any PR Coverage report or coverage summary produced during the current chat session.

If no PR Coverage is found, skip to the end -- this step is optional.

在步骤4使用的同一来源中查找PR覆盖率部分：

日志文件：如果使用了日志文件，查找
```
## PR Coverage
```
或
```
## Coverage
```
部分并提取其完整内容。
当前聊天会话：如果未使用日志文件，查找当前聊天会话中生成的任何PR覆盖率报告或覆盖率摘要。

如果未找到PR覆盖率，直接结束——此步骤为可选。

10. Post PR Coverage Comment

10. 发布PR覆盖率评论

This step runs only if PR Coverage was found in Step 9. It must be the very last action -- execute it after all other steps (including the review submission and result report) are complete.

Post the coverage report as a standalone PR comment:

bash

gh pr comment $PR_NUMBER --body "$(cat <<'EOF'
<coverage-content>
EOF
)"

Use the PR Coverage content exactly as found -- do not modify, summarize, or reformat it
This comment is independent of the review; post it even if no review was submitted in Step 6
This must be the very last API call in the entire procedure to ensure the coverage comment appears at the bottom of the PR conversation

仅当步骤9中找到PR覆盖率时才执行此步骤。这必须是最后一项操作——在完成所有其他步骤（包括评审提交和结果报告）后执行。

将覆盖率报告作为独立的PR评论发布：

bash

gh pr comment $PR_NUMBER --body "$(cat <<'EOF'
<coverage-content>
EOF
)"

完全按原样使用PR覆盖率内容——不要修改、总结或重新格式化
此评论独立于评审；即使步骤6中未提交评审，也要发布
这必须是整个流程中的最后一个API调用，以确保覆盖率评论显示在PR对话的底部

Important Notes

重要说明

Use
```
APPROVE
```
when no critical issues are found, otherwise use
```
COMMENT
```
. Never use
```
REQUEST_CHANGES
```
unless the user explicitly asks
The
```
line
```
field in review comments must reference a line that appears in the diff -- comments on unchanged lines will be rejected by the API
For multi-line suggestions, use
```
start_line
```
and
```
line
```
together to define the range being replaced; both must be within the diff hunk
An empty suggestion block (
```
```suggestion\n```
```
) means "delete these lines"
The content inside
```
```suggestion ```
```
replaces the selected line(s) verbatim -- ensure correct indentation and formatting
Never fabricate issues -- only flag genuine concerns backed by evidence in the code

未发现严重问题时使用
```
APPROVE
```
，否则使用
```
COMMENT
```
。除非用户明确要求，否则绝不使用
```
REQUEST_CHANGES
```
评审评论中的
```
line
```
字段必须引用差异中出现的行——针对未更改行的评论将被API拒绝
对于多行建议，同时使用
```
start_line
```
和
```
line
```
定义要替换的范围；两者都必须在差异块内
空的建议块（
```
```suggestion\n```
```
）表示「删除这些行」
```
```suggestion ```
```
内的内容将逐字替换所选代码行——确保缩进和格式正确
绝不能编造问题——仅标记有代码证据支持的真实问题