github-pr-assess-comments

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

github-pr-assess-comments

Analyses every unresolved review thread on the Pull Request associated with the current branch. For each comment it evaluates whether the feedback is valid and produces a concrete fix proposal, then renders a summary table.

分析当前分支对应的Pull Request（PR）上的所有未解决评审线程。针对每条评论评估反馈是否有效，并给出具体的修复建议，最后生成汇总表格。

When to use

使用场景

When the user asks to review, triage, or assess PR comments / review feedback
When the user wants a summary of outstanding review threads and suggested fixes
When the user wants to know what reviewers said and how to address it

当用户要求评审、分类或评估PR评论/评审反馈时
当用户需要未解决评审线程的汇总信息及建议修复方案时
当用户想了解评审者的意见以及如何解决这些意见时

Instructions

操作步骤

1. Guard: verify a PR exists for the current branch

1. 校验：确认当前分支存在对应的PR

bash

CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
PR_JSON=$(gh pr view --json number,url,headRefName 2>/dev/null)

If the command fails or returns nothing, stop immediately and tell the user:

"No open Pull Request found for the current branch (
<branch>
). Please open a PR first."

Extract the PR number and URL:

bash

PR_NUMBER=$(echo "$PR_JSON" | jq '.number')
PR_URL=$(echo "$PR_JSON" | jq -r '.url')

bash

CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
PR_JSON=$(gh pr view --json number,url,headRefName 2>/dev/null)

如果命令执行失败或无返回结果，立即停止并告知用户：

"当前分支（
<branch>
）未找到已开启的Pull Request，请先创建PR。"

提取PR编号和URL：

bash

PR_NUMBER=$(echo "$PR_JSON" | jq '.number')
PR_URL=$(echo "$PR_JSON" | jq -r '.url')

2. Resolve the repository owner and name

2. 解析仓库所有者和名称

bash

REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
OWNER=$(echo "$REPO" | cut -d'/' -f1)
REPO_NAME=$(echo "$REPO" | cut -d'/' -f2)

bash

REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
OWNER=$(echo "$REPO" | cut -d'/' -f1)
REPO_NAME=$(echo "$REPO" | cut -d'/' -f2)

3. Fetch all unresolved review threads via GraphQL

3. 通过GraphQL获取所有未解决的评审线程

Use the GitHub GraphQL API to retrieve review threads with their resolved state and associated comments:

bash

gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $pr) {
      reviewThreads(first: 100) {
        nodes {
          isResolved
          path
          line
          comments(first: 10) {
            nodes {
              databaseId
              author { login }
              body
              createdAt
            }
          }
        }
      }
    }
  }
}' -f owner="$OWNER" -f repo="$REPO_NAME" -F pr="$PR_NUMBER"

Filter to keep only threads where

isResolved

false

. If no unresolved threads are found, tell the user:

"No unresolved review comments found on PR #
<number>
. All threads are resolved." Then stop.

使用GitHub GraphQL API获取包含解决状态及关联评论的评审线程：

bash

gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $pr) {
      reviewThreads(first: 100) {
        nodes {
          isResolved
          path
          line
          comments(first: 10) {
            nodes {
              databaseId
              author { login }
              body
              createdAt
            }
          }
        }
      }
    }
  }
}' -f owner="$OWNER" -f repo="$REPO_NAME" -F pr="$PR_NUMBER"

筛选出

isResolved

为

false

的线程。如果未找到未解决线程，告知用户：

"PR #
<number>
上未发现未解决的评审评论，所有线程均已处理。" 随后停止操作。

4. Gather code context for each unresolved thread

4. 收集每条未解决线程的代码上下文

For each unresolved thread, retrieve the relevant section of the file at the commented line to understand the surrounding code:

bash

undefined

针对每条未解决线程，获取评论所在行的相关文件片段，以理解代码上下文：

bash

undefined

Get the file content at the PR head

获取PR头部的文件内容

gh api "repos/$OWNER/$REPO_NAME/contents/<path>?ref=$CURRENT_BRANCH"
--jq '.content' | base64 --decode


Extract approximately 10 lines around the commented line to give enough context for assessment.

Also fetch the PR diff to understand what changed:

```bash
gh pr diff "$PR_NUMBER"

gh api "repos/$OWNER/$REPO_NAME/contents/<path>?ref=$CURRENT_BRANCH"
--jq '.content' | base64 --decode


提取评论行前后约10行内容，为评估提供足够上下文。

同时获取PR差异以了解代码变更：

```bash
gh pr diff "$PR_NUMBER"

5. Assess each comment and propose a fix

5. 评估每条评论并提出修复方案

For every unresolved comment, perform the following analysis using the comment body, the file context, and the PR diff:

Validity assessment — classify the comment as one of:

```
✅ Valid
```
— the feedback identifies a real issue (bug, security flaw, style violation, missing logic, etc.)
```
⚠️ Debatable
```
— the feedback is a matter of preference or opinion; a reasonable engineer could disagree
```
❌ Invalid
```
— the feedback is factually incorrect, already addressed, or not applicable to the changed code

Fix proposal — for each comment, produce a short, concrete action. Examples:

For
```
✅ Valid
```
: a specific code change, refactor, or addition (inline snippet if short enough)
For
```
⚠️ Debatable
```
: explain the trade-off and suggest a response or minor accommodation
For
```
❌ Invalid
```
: suggest replying with a short explanation of why the comment does not apply

结合评论内容、文件上下文和PR差异，对每条未解决评论执行以下分析：

有效性评估 — 将评论分为以下三类：

```
✅ 有效
```
— 反馈指出了真实问题（如bug、安全漏洞、风格违规、逻辑缺失等）
```
⚠️ 有争议
```
— 反馈属于偏好或观点问题，合理的工程师可能会有不同看法
```
❌ 无效
```
— 反馈存在事实错误、已被处理或与变更代码无关

修复建议 — 针对每条评论给出简短、具体的操作：

对于
```
✅ 有效
```
：给出具体的代码修改、重构或补充建议（如果简短可直接提供代码片段）
对于
```
⚠️ 有争议
```
：解释权衡点，并建议回复或做出微小调整
对于
```
❌ 无效
```
：建议回复简短说明该评论不适用的原因

6. Render the summary table

6. 生成汇总表格

Print the results as a Markdown table with the following columns:

#	File & Line	Author	Comment (excerpt)	Validity	Proposed Fix

Rules for the table:

# — sequential index (1-based)
File & Line — relative file path and line number from the thread (e.g.
```
src/foo.ts:42
```
)
Author — GitHub login of the comment author
Comment (excerpt) — first 80 characters of the comment body, truncated with
```
…
```
if longer
Validity — one of
```
✅ Valid
```
,
```
⚠️ Debatable
```
, or
```
❌ Invalid
```
Proposed Fix — concise action (≤120 chars); longer proposals go in a numbered list below the table, referenced by index

After the table, include a Detail section that expands every entry whose proposed fix exceeded 120 characters, numbered to match the table index.

将结果以Markdown表格形式打印，包含以下列：

序号	文件与行号	作者	评论（摘要）	有效性	建议修复方案

表格规则：

序号 — 连续索引（从1开始）
文件与行号 — 线程对应的相对文件路径和行号（例如
```
src/foo.ts:42
```
）
作者 — 评论作者的GitHub登录名
评论（摘要） — 评论内容的前80个字符，超出部分用
```
…
```
截断
有效性 — 为
```
✅ 有效
```
、
```
⚠️ 有争议
```
或
```
❌ 无效
```
之一
建议修复方案 — 简洁的操作描述（≤120字符）；较长的建议放在表格下方的编号列表中，通过序号关联

表格之后添加详细说明部分，展开所有建议修复方案超过120字符的条目，编号与表格序号对应。

Key constraints

核心约束

All GitHub operations MUST use the
```
gh
```
CLI — no direct API calls with
```
curl
```
unless
```
gh api
```
is used.
Never fabricate comments or code that are not retrieved from the API.
Keep assessment objective: base validity on correctness, clarity, and relevance to the diff — not on personal style preferences unless a linter/style guide is referenced.
Never expose secrets, credentials, or PII found in comment bodies or code.
If
```
gh
```
is not installed or not authenticated, stop and tell the user to install/authenticate it first.

所有GitHub操作必须使用
```
gh
```
CLI — 除非使用
```
gh api
```
，否则禁止直接用
```
curl
```
调用API。
不得编造未从API获取的评论或代码内容。
评估需保持客观：有效性基于正确性、清晰度及与差异的相关性 — 除非引用了代码检查工具/风格指南，否则不得基于个人风格偏好判断。
不得泄露评论内容或代码中发现的机密、凭证或个人身份信息（PII）。
如果未安装
```
gh
```
或未完成认证，停止操作并告知用户先安装/认证
```
gh
```
。