Back to Details

review-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review PR

评审PR

Overview

概述

Perform a thorough review-only PR assessment and return a structured recommendation on readiness for /prepare-pr.
执行全面的仅评审模式PR评估，并返回关于是否可进入/prepare-pr流程的结构化建议。

Inputs

输入要求

  • Ask for PR number or URL.
  • If missing, always ask. Never auto-detect from conversation.
  • If ambiguous, ask.
  • 请求提供PR编号或URL。
  • 如果缺失，务必询问。切勿从对话中自动检测。
  • 如果信息模糊，及时询问。

Safety

安全规则

  • Never push to 
    main
    or 
    origin/main
    , not during review, not ever.
  • Do not run 
    git push
    at all during review. Treat review as read only.
  • Do not stop or kill the gateway. Do not run gateway stop commands. Do not kill processes on port 18792.
  • 切勿推送到
    main
    或
    origin/main
    ，无论何时都不允许，评审期间也不行。
  • 评审过程中完全禁止执行
    git push
    命令。评审仅为只读操作。
  • 请勿停止或关闭网关。不要执行网关停止命令，也不要终止端口18792上的进程。

Execution Rule

执行规则

  • Execute the workflow. Do not stop after printing the TODO checklist.
  • If delegating, require the delegate to run commands and capture outputs, not a plan.
  • 执行完整工作流。打印待办事项清单后不要停止操作。
  • 如果委托他人执行，要求被委托者运行命令并捕获输出，而不是仅提供计划。

Known Failure Modes

已知失败模式

  • If you see "fatal: not a git repository", you are in the wrong directory. Move to the repository root and retry.
  • Do not stop after printing the checklist. That is not completion.
  • 如果出现“fatal: not a git repository”错误，说明你处于错误目录。切换到仓库根目录后重试。
  • 打印清单后不要停止操作，这并不代表完成。

Writing Style for Output

输出写作风格

  • Write casual and direct.
  • Avoid em dashes and en dashes. Use commas or separate sentences.
  • 语气随意、直接。
  • 避免使用破折号，改用逗号或拆分句子。

Completion Criteria

完成标准

  • Run the commands in the worktree and inspect the PR directly.
  • Produce the structured review sections A through J.
  • Save the full review to 
    .local/review.md
    inside the worktree.
  • Save PR metadata handoff to 
    .local/pr-meta.env
    inside the worktree.
  • 在工作区中运行命令并直接检查PR。
  • 生成从A到J的结构化评审章节。
  • 将完整评审内容保存到工作区内的
    .local/review.md
    文件中。
  • 将PR元数据交接信息保存到工作区内的
    .local/pr-meta.env
    文件中。

First: Create a TODO Checklist

第一步：创建待办事项清单

Create a checklist of all review steps, print it, then continue and execute the commands.
创建包含所有评审步骤的清单，打印后继续执行命令。

Setup: Use a Worktree

设置：使用工作区

Use an isolated worktree for all review work.
sh
repo_root=$(git rev-parse --show-toplevel)
cd "$repo_root"
gh auth status

WORKTREE_DIR=".worktrees/pr-<PR>"
git fetch origin main
使用独立的工作区完成所有评审工作。
sh
repo_root=$(git rev-parse --show-toplevel)
cd "$repo_root"
gh auth status

WORKTREE_DIR=".worktrees/pr-<PR>"
git fetch origin main

Reuse existing worktree if it exists, otherwise create new

若工作区已存在则复用，否则创建新工作区

if [ -d "$WORKTREE_DIR" ]; then git worktree list cd "$WORKTREE_DIR" git fetch origin main git checkout -B temp/pr-<PR> origin/main else git worktree add "$WORKTREE_DIR" -b temp/pr-<PR> origin/main cd "$WORKTREE_DIR" fi
if [ -d "$WORKTREE_DIR" ]; then git worktree list cd "$WORKTREE_DIR" git fetch origin main git checkout -B temp/pr-<PR> origin/main else git worktree add "$WORKTREE_DIR" -b temp/pr-<PR> origin/main cd "$WORKTREE_DIR" fi

Create local scratch space that persists across /review-pr to /prepare-pr to /merge-pr

创建本地临时目录，用于在/review-pr、/prepare-pr、/merge-pr流程间持久化数据

mkdir -p .local

Run all commands inside the worktree directory.
Start on `origin/main` so you can check for existing implementations before looking at PR code.
mkdir -p .local

所有命令都在工作区目录内执行。
从`origin/main`分支开始，以便在查看PR分支前检查是否已有相关实现。

Steps

步骤

  1. Identify PR meta and context
sh
pr_meta_json=$(gh pr view <PR> --json number,title,state,isDraft,author,baseRefName,headRefName,headRefOid,headRepository,url,body,labels,assignees,reviewRequests,files,additions,deletions,statusCheckRollup)
printf '%s\n' "$pr_meta_json" | jq '{number,title,url,state,isDraft,author:.author.login,base:.baseRefName,head:.headRefName,headSha:.headRefOid,headRepo:.headRepository.nameWithOwner,additions,deletions,files:(.files|length),body}'

cat > .local/pr-meta.env <<EOF
PR_NUMBER=$(printf '%s\n' "$pr_meta_json" | jq -r .number)
PR_URL=$(printf '%s\n' "$pr_meta_json" | jq -r .url)
PR_AUTHOR=$(printf '%s\n' "$pr_meta_json" | jq -r .author.login)
PR_BASE=$(printf '%s\n' "$pr_meta_json" | jq -r .baseRefName)
PR_HEAD=$(printf '%s\n' "$pr_meta_json" | jq -r .headRefName)
PR_HEAD_SHA=$(printf '%s\n' "$pr_meta_json" | jq -r .headRefOid)
PR_HEAD_REPO=$(printf '%s\n' "$pr_meta_json" | jq -r .headRepository.nameWithOwner)
EOF

ls -la .local/pr-meta.env
  1. Check if this already exists in main before looking at the PR branch
  • Identify the core feature or fix from the PR title and description.
  • Search for existing implementations using keywords from the PR title, changed file paths, and function or component names from the diff.
sh
undefined
  1. 识别PR元数据和上下文
sh
pr_meta_json=$(gh pr view <PR> --json number,title,state,isDraft,author,baseRefName,headRefName,headRefOid,headRepository,url,body,labels,assignees,reviewRequests,files,additions,deletions,statusCheckRollup)
printf '%s\n' "$pr_meta_json" | jq '{number,title,url,state,isDraft,author:.author.login,base:.baseRefName,head:.headRefName,headSha:.headRefOid,headRepo:.headRepository.nameWithOwner,additions,deletions,files:(.files|length),body}'

cat > .local/pr-meta.env <<EOF
PR_NUMBER=$(printf '%s\n' "$pr_meta_json" | jq -r .number)
PR_URL=$(printf '%s\n' "$pr_meta_json" | jq -r .url)
PR_AUTHOR=$(printf '%s\n' "$pr_meta_json" | jq -r .author.login)
PR_BASE=$(printf '%s\n' "$pr_meta_json" | jq -r .baseRefName)
PR_HEAD=$(printf '%s\n' "$pr_meta_json" | jq -r .headRefName)
PR_HEAD_SHA=$(printf '%s\n' "$pr_meta_json" | jq -r .headRefOid)
PR_HEAD_REPO=$(printf '%s\n' "$pr_meta_json" | jq -r .headRepository.nameWithOwner)
EOF

ls -la .local/pr-meta.env
  1. 在查看PR分支前，检查main分支是否已有相关实现
  • 从PR标题和描述中提取核心功能或修复点。
  • 使用PR标题中的关键词、更改的文件路径以及差异中的函数或组件名称，搜索现有实现。
sh
undefined

Use keywords from the PR title and changed files

使用PR标题和更改文件中的关键词

rg -n "<keyword_from_pr_title>" -S src packages apps ui || true rg -n "<function_or_component_name>" -S src packages apps ui || true
git log --oneline --all --grep="<keyword_from_pr_title>" | head -20

If it already exists, call it out as a BLOCKER or at least IMPORTANT.

3. Claim the PR

Assign yourself so others know someone is reviewing. Skip if the PR looks like spam or is a draft you plan to recommend closing.

```sh
gh_user=$(gh api user --jq .login)
gh pr edit <PR> --add-assignee "$gh_user" || echo "Could not assign reviewer, continuing"
  1. Read the PR description carefully
Use the body from step 1. Summarize goal, scope, and missing context.
  1. Read the diff thoroughly
Minimum:
sh
gh pr diff <PR>
If you need full code context locally, fetch the PR head to a local ref and diff it. Do not create a merge commit.
sh
git fetch origin pull/<PR>/head:pr-<PR> --force
mb=$(git merge-base origin/main pr-<PR>)
rg -n "<keyword_from_pr_title>" -S src packages apps ui || true rg -n "<function_or_component_name>" -S src packages apps ui || true
git log --oneline --all --grep="<keyword_from_pr_title>" | head -20

如果已有相关实现，需将其标记为阻塞问题（BLOCKER）或至少是重要问题（IMPORTANT）。

3. 认领PR

将自己设为评审人，让其他人知道已有专人在评审。如果PR看起来是垃圾信息或你建议关闭的草稿PR，可跳过此步骤。

```sh
gh_user=$(gh api user --jq .login)
gh pr edit <PR> --add-assignee "$gh_user" || echo "Could not assign reviewer, continuing"
  1. 仔细阅读PR描述
使用步骤1中获取的PR正文内容，总结目标、范围和缺失的上下文信息。
  1. 全面查看代码差异
最低要求：
sh
gh pr diff <PR>
如果需要本地查看完整代码上下文，可将PR的头部分支拉取到本地引用并进行差异对比。请勿创建合并提交。
sh
git fetch origin pull/<PR>/head:pr-<PR> --force
mb=$(git merge-base origin/main pr-<PR>)

Show only this PR patch relative to merge-base, not total branch drift

仅显示相对于合并基准的PR补丁，不显示分支的整体差异

git diff --stat "$mb"..pr-<PR> git diff "$mb"..pr-<PR>

If you want to browse the PR version of files directly, temporarily check out `pr-<PR>` in the worktree. Do not commit or push. Return to `temp/pr-<PR>` and reset to `origin/main` afterward.

```sh
git diff --stat "$mb"..pr-<PR> git diff "$mb"..pr-<PR>

如果需要直接浏览PR版本的文件，可临时在工作区中检出`pr-<PR>`分支。请勿提交或推送。之后需切回`temp/pr-<PR>`分支并重置到`origin/main`。

```sh

Use only if needed

仅在需要时使用

git checkout pr-<PR>

git checkout pr-<PR>

git branch --show-current

git branch --show-current

...inspect files...

...inspect files...

git checkout temp/pr-<PR> git checkout -B temp/pr-<PR> origin/main git branch --show-current

6. Validate the change is needed and valuable

Be honest. Call out low value AI slop.

7. Evaluate implementation quality

Review correctness, design, performance, and ergonomics.

8. Perform a security review

Assume OpenClaw subagents run with full disk access, including git, gh, and shell. Check auth, input validation, secrets, dependencies, tool safety, and privacy.

9. Review tests and verification

Identify what exists, what is missing, and what would be a minimal regression test.

If you run local tests in the worktree, bootstrap dependencies first:

```sh
if [ ! -x node_modules/.bin/vitest ]; then
  pnpm install --frozen-lockfile
fi
  1. Check docs
Check if the PR touches code with related documentation such as README, docs, inline API docs, or config examples.
  • If docs exist for the changed area and the PR does not update them, flag as IMPORTANT.
  • If the PR adds a new feature or config option with no docs, flag as IMPORTANT.
  • If the change is purely internal with no user-facing impact, skip this.
  1. Check changelog
Check if 
CHANGELOG.md
exists and whether the PR warrants an entry.
  • If the project has a changelog and the PR is user-facing, flag missing entry as IMPORTANT.
  • Leave the change for /prepare-pr, only flag it here.
  1. Answer the key question
Decide if /prepare-pr can fix issues or the contributor must update the PR.
  1. Save findings to the worktree
Write the full structured review sections A through J to 
.local/review.md
. Create or overwrite the file and verify it exists and is non-empty.
sh
ls -la .local/review.md
wc -l .local/review.md
  1. Output the structured review
Produce a review that matches what you saved to 
.local/review.md
.
A) TL;DR recommendation
  • One of: READY FOR /prepare-pr | NEEDS WORK | NEEDS DISCUSSION | NOT USEFUL (CLOSE)
  • 1 to 3 sentences.
B) What changed
C) What is good
D) Security findings
E) Concerns or questions (actionable)
  • Numbered list.
  • Mark each item as BLOCKER, IMPORTANT, or NIT.
  • For each, point to file or area and propose a concrete fix.
F) Tests
G) Docs status
  • State if related docs are up to date, missing, or not applicable.
H) Changelog
  • State if 
    CHANGELOG.md
    needs an entry and which category.
I) Follow ups (optional)
J) Suggested PR comment (optional)
git checkout temp/pr-<PR> git checkout -B temp/pr-<PR> origin/main git branch --show-current

6. 验证更改的必要性和价值

保持客观诚实。如果是低价值的AI生成内容，需明确指出。

7. 评估实现质量

评审正确性、设计、性能和易用性。

8. 执行安全评审

假设OpenClaw子代理拥有完整磁盘访问权限，包括git、gh和shell权限。检查认证、输入验证、密钥、依赖项、工具安全性和隐私保护情况。

9. 评审测试和验证环节

识别已有的测试、缺失的测试以及最小化回归测试的方案。

如果在工作区中运行本地测试，需先初始化依赖项：

```sh
if [ ! -x node_modules/.bin/vitest ]; then
  pnpm install --frozen-lockfile
fi
  1. 检查文档
检查PR是否涉及带有相关文档的代码，例如README、文档、内联API文档或配置示例。
  • 如果更改区域已有文档但PR未更新，标记为重要问题（IMPORTANT）。
  • 如果PR添加了新功能或配置选项但未提供文档，标记为重要问题（IMPORTANT）。
  • 如果更改仅为内部实现，无用户可见影响，可跳过此步骤。
  1. 检查变更日志
检查项目是否存在
CHANGELOG.md
，以及PR是否需要添加日志条目。
  • 如果项目有变更日志且PR面向用户，缺失条目需标记为重要问题（IMPORTANT）。
  • 日志条目的添加工作留给/prepare-pr流程处理，此处仅需标记问题。
  1. 回答核心问题
决定是通过/prepare-pr流程修复问题，还是需要贡献者更新PR。
  1. 将结果保存到工作区
将从A到J的完整结构化评审内容写入
.local/review.md
文件。 创建或覆盖该文件，并验证文件已存在且内容非空。
sh
ls -la .local/review.md
wc -l .local/review.md
  1. 输出结构化评审结果
生成与保存到
.local/review.md
中一致的评审内容。
A) 简短结论（TL;DR）
  • 以下选项之一：可进入/prepare-pr流程 | 需要修改 | 需要讨论 | 无价值（建议关闭）
  • 1-3句话总结。
B) 变更内容
C) 亮点
D) 安全发现
E) 关注点或疑问（可执行）
  • 编号列表。
  • 每个条目标记为阻塞问题（BLOCKER）、重要问题（IMPORTANT）或小问题（NIT）。
  • 每个条目需指向具体文件或区域，并提出具体修复建议。
F) 测试情况
G) 文档状态
  • 说明相关文档是否更新、缺失或不适用。
H) 变更日志
  • 说明
    CHANGELOG.md
    是否需要添加条目以及对应的分类。
I) 后续工作（可选）
J) 建议的PR评论（可选）

Guardrails

防护规则

  • Worktree only.
  • Do not delete the worktree after review.
  • Review only, do not merge, do not push.
  • 仅在工作区内操作。
  • 评审完成后请勿删除工作区。
  • 仅执行评审操作，请勿合并、推送代码。