Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Gather Context

收集上下文

Run the following command to check the current branch:
  1. git branch --show-current
    — check current branch
运行以下命令检查当前分支：
  1. git branch --show-current
    — 检查当前分支

Identify Target PR

确定目标PR

Parse 
$ARGUMENTS
to extract a PR number or URL. If not provided, detect from the current branch:
gh pr view --json number --jq '.number' 2>/dev/null
If no PR is found, ask the user to specify one.
解析
$ARGUMENTS
以提取PR编号或URL。 如果未提供，则从当前分支自动检测：
gh pr view --json number --jq '.number' 2>/dev/null
如果未找到PR，请要求用户指定一个。

Step 1: Collect Review Comments

步骤1：收集审核评论

Fetch all review comments on the PR (both human and bot/AI):
gh api repos/{owner}/{repo}/pulls/{number}/comments --jq '.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login, created_at: .created_at}'
Also fetch PR-level review summaries:
gh api repos/{owner}/{repo}/pulls/{number}/reviews --jq '.[] | {id: .id, user: .user.login, state: .state, body: .body}'
Include all reviewers — human teammates and AI bots alike. Do NOT filter by user type.
获取该PR上的所有审核评论（包括人工和机器人/AI评论）：
gh api repos/{owner}/{repo}/pulls/{number}/comments --jq '.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login, created_at: .created_at}'
同时获取PR级别的审核总结：
gh api repos/{owner}/{repo}/pulls/{number}/reviews --jq '.[] | {id: .id, user: .user.login, state: .state, body: .body}'
包含所有审核者——无论是团队成员还是AI机器人，不要按用户类型过滤。

Step 2: Analyze Each Suggestion

步骤2：分析每条建议

For each review comment:
  1. Read the referenced file and surrounding code context (at least 20 lines around the mentioned line).
  2. Understand the reviewer's suggestion in the context of the actual code.
  3. Evaluate the suggestion's validity:
CategoryCriteria
ValidIdentifies a real bug, security issue, or meaningful improvement
DebatableStylistic preference or trade-off that could go either way
IncorrectMisunderstands the code, context, or project conventions
Already handledThe concern is addressed elsewhere in the codebase
对于每条审核评论：
  1. 阅读引用的文件及周边代码上下文（提及行前后至少20行）。
  2. 结合实际代码理解审核者的建议。
  3. 评估建议的有效性：
类别判定标准
有效指出了真实的bug、安全问题或有意义的改进点
存在争议属于风格偏好或可权衡的选择，两种处理方式均可
不正确对代码、上下文或项目规范存在误解
已处理该问题已在代码库的其他地方得到解决

Step 3: Present Findings

步骤3：呈现分析结果

Group findings by category and present to the user:
undefined
按类别分组分析结果并呈现给用户：
undefined

Review Analysis for PR #{number}

PR #{number} 审核分析

✅ Valid Suggestions (recommended to apply)

✅ 有效建议（推荐采纳）

  1. [file.py:42] {summary}
    • Reviewer said: {brief quote}
    • Assessment: {why this is valid, what the fix should be}
  1. [file.py:42] {summary}
    • 审核者：{brief quote}
    • 评估：{why this is valid, what the fix should be}

🤔 Debatable

🤔 存在争议

  1. [file.py:78] {summary}
    • Reviewer said: {brief quote}
    • Pros: {benefits of applying}
    • Cons: {reasons to skip}
  1. [file.py:78] {summary}
    • 审核者：{brief quote}
    • 采纳优势：{benefits of applying}
    • 不采纳理由：{reasons to skip}

❌ Can Safely Ignore

❌ 可安全忽略

  1. [file.py:15] {summary}
    • Reviewer said: {brief quote}
    • Why: {reason this is not applicable — e.g., misunderstood context, project convention differs}
undefined
  1. [file.py:15] {summary}
    • 审核者：{brief quote}
    • 原因：{reason this is not applicable — e.g., misunderstood context, project convention differs}
undefined

Step 4: Discuss and Apply

步骤4：讨论与实施

For each Valid or Debatable suggestion:
  1. Ask the user whether to apply the change.
  2. If approved, make the code change using Edit.
  3. After all approved changes are applied, suggest a commit message following the project's commit convention (e.g., 
    fix: 리뷰 피드백 반영
    ).
对于每条有效或存在争议的建议：
  1. 询问用户是否采纳该修改。
  2. 若获得批准，使用编辑功能修改代码。
  3. 在所有获批修改完成后，根据项目的提交规范建议提交信息（例如：
    fix: 리뷰 피드백 반영
    ）。

Step 5: Reply to Review Comments

步骤5：回复审核评论

After the commit is created, reply to each review comment on GitHub to record the resolution.
For each comment that was discussed (Valid, Debatable, or Ignored):
gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies -f body="{reply_body}"
提交创建完成后，在GitHub上回复每条审核评论，记录解决状态。
对于每条已讨论的评论（有效、存在争议或已忽略）：
gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies -f body="{reply_body}"

Reply format (concise, bulleted):

回复格式（简洁，使用项目符号）：

If applied:
- ✅ 반영 완료
- 커밋: {short_sha}
- 변경: {1-line summary of what was changed}
If not applied (with reason):
- ⏭️ 미반영
- 사유: {concise reason — e.g., 프로젝트 컨벤션과 상충, 이미 다른 방식으로 처리됨}
Present all planned replies to the user for approval before posting.
Important:
  • Do NOT apply any code changes without explicit user approval for each item.
  • Do NOT post reply comments without explicit user approval.
  • Read the actual code context before judging — do not rely solely on the review comment.
  • Consider the project's existing patterns, conventions, and CLAUDE.md instructions.
  • Be honest when a review catches a genuine issue — do not dismiss valid feedback.
  • If no review comments are found, inform the user.
若已采纳：
- ✅ 已采纳
- 提交: {short_sha}
- 修改内容: {1-line summary of what was changed}
若未采纳（附理由）：
- ⏭️ 未采纳
- 理由: {concise reason — e.g., 与项目规范冲突，已通过其他方式处理}
在发布前，将所有计划好的回复呈现给用户以获得批准。
注意事项：
  • 未经用户对每个项目的明确批准，不得进行任何代码修改。
  • 未经用户明确批准，不得发布回复评论。
  • 评判前请阅读实际代码上下文，不要仅依赖审核评论。
  • 考虑项目现有的模式、规范以及CLAUDE.md中的说明。
  • 当审核指出真实问题时，请如实反馈，不要忽略有效建议。
  • 若未找到审核评论，请告知用户。