review-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

review-pr

Review a GitHub pull request end-to-end: gather what the PR claims, get its code into view without disturbing anything, judge it with scrutinize, and close with an explicit disposition — send it back, fix it yourself, or keep it in chat.

Fork PRs are read-only, no exceptions: if

isCrossRepository

is true, the fork's code never gets checked out into the project working tree and never executes on this machine — regardless of how clean

git status

looks. A clean tree protects your WIP; it does nothing about untrusted code.

全方位审核GitHub拉取请求：收集PR声明的内容，在不干扰任何内容的前提下查看其代码，通过scrutinize进行评估，并以明确的处理方式收尾——将PR退回、自行修复或仅保留在聊天中。

**跨仓库PR为只读状态，无例外：**如果

isCrossRepository

为true，无论

git status

显示多么干净，fork的代码永远不会被检出到项目工作区，也永远不会在本机执行。干净的工作区仅能保护你的在开发工作（WIP），无法防范不可信代码。

Workflow

工作流程

Run in order. Steps 4 and 5 are not optional.

按顺序执行。步骤4和5为必填项。

1. Context — what does the PR claim?

1. 背景信息——PR声明了什么？

bash

gh pr view <n> --json title,body,author,isCrossRepository,baseRefName,headRefName,mergeable,url,files
gh pr checks <n>
gh issue view <m>       # for EVERY issue the body references — its acceptance criteria are the spec
gh pr view <n> --comments   # existing discussion, if any

bash

gh pr view <n> --json title,body,author,isCrossRepository,baseRefName,headRefName,mergeable,url,files
gh pr checks <n>
gh issue view <m>       # 针对PR正文中提及的每一个Issue——其验收标准即为审核依据
gh pr view <n> --comments   # 查看现有讨论（如有）

2. Workspace — the fork gate comes first

2. 工作区——先执行Fork校验

Decide in this order. The first matching branch wins; do not read further.

Is
isCrossRepository: true
? (from the step-1
```
gh pr view
```
— check this BEFORE
```
git status
```
, a clean tree changes nothing here) → first, state in your reply, verbatim: "Fork PR — read-only:
git show
only, no checkout." — then act on it:
```
git fetch origin pull/<n>/head:pr-<n>
```
, read via
```
git show pr-<n>:<path>
```
; when you want Read/Grep-style browsing, mount a read-only throwaway worktree OUTSIDE the project (
```
git worktree add "$TMP/pr-<n>" pr-<n>
```
) and run nothing in it. Never
```
gh pr checkout
```
, never
```
git switch --detach FETCH_HEAD
```
, never
```
git checkout pr-<n>
```
, never add the fork as a remote. See the fork rule below.
Same-repo PR, clean tree →
```
gh pr checkout <n>
```
— note the branch you came from.
Same-repo PR, dirty tree (any WIP at all) → do NOT stash, do NOT checkout.
```
git fetch origin pull/<n>/head:pr-<n>
```
, read full files via
```
git show pr-<n>:<path>
```
, or mount a throwaway worktree (
```
git worktree add <tmp> pr-<n>
```
) to browse with file tools or run tests.

按以下顺序判断，匹配到第一个分支后即停止，无需继续查看后续规则。

是否
isCrossRepository: true
？（来自步骤1的
```
gh pr view
```
结果——务必在执行
```
git status
```
前检查，干净的工作区对此规则无影响）→ 首先在回复中逐字说明：“跨仓库PR——只读状态：仅使用
git show
，禁止检出。” —— 然后执行操作：
```
git fetch origin pull/<n>/head:pr-<n>
```
，通过
```
git show pr-<n>:<path>
```
查看代码；若需要以读/搜索方式浏览，在项目外部挂载一个只读临时工作区（
```
git worktree add "$TMP/pr-<n>" pr-<n>
```
），且不在其中执行任何命令。绝对禁止使用
```
gh pr checkout
```
、
```
git switch --detach FETCH_HEAD
```
、
```
git checkout pr-<n>
```
，也禁止添加该fork为远程仓库。详见下方Fork规则。
同仓库PR，工作区干净 → 执行
```
gh pr checkout <n>
```
——记录当前切换前的分支。
同仓库PR，工作区有未提交内容（任何WIP） → 禁止stash，禁止检出。执行
```
git fetch origin pull/<n>/head:pr-<n>
```
，通过
```
git show pr-<n>:<path>
```
查看完整文件，或挂载临时工作区（
```
git worktree add <tmp> pr-<n>
```
）以使用文件工具浏览或运行测试。

3. Judge — REQUIRED SUB-SKILL: scrutinize

3. 评估——必填子技能：scrutinize

Invoke dev-workflows:scrutinize on the PR. Scope = merge-base diff (

git diff <base>...pr-<n>

); the claims to verify = PR body + linked-issue acceptance criteria. Scrutinize owns the intent-questioning, the end-to-end trace, and the findings report — do not duplicate or dilute it here.

调用dev-workflows:scrutinize对PR进行评估。范围为合并基准差异（

git diff <base>...pr-<n>

）；需要验证的内容为PR正文+关联Issue的验收标准。scrutinize负责核查意图、端到端追踪及生成结果报告——请勿在此重复或简化该环节。

4. Disposition — REQUIRED closing step

4. 处理方式——必填收尾步骤

The review is not finished when the verdict is delivered. If there are findings, ask the user this exact three-option question — all three options every time, never skip it, never pick one silently:

"What do you want done with these findings — (a) send back: I post this review on the PR for the author to fix, (b) fix it: I apply the fixes on the PR branch and push, or (c) chat only: nothing leaves this conversation?"

(a) Send back — draft the review text, show it, and only on approval post it:
```
gh pr review <n> --request-changes --body-file <draft>
```
(
```
--comment
```
if non-blocking).
(b) Fix it — check out the PR branch, apply the fixes, commit, push to the PR head branch. (Fork PRs: possible only when "maintainers can edit" is on — otherwise offer send-back.)
(c) Chat only — nothing leaves the conversation.

Nothing is posted, pushed, approved, or merged before the user picks. If the user already signalled they intend to merge, confirm who merges as a separate question AFTER the disposition pick. If scrutinize found nothing, report what was traced (no rubber-stamps) and offer: approve (

gh pr review <n> --approve

) or chat-only.

仅给出审核结论不算完成审核。若存在问题，需向用户询问以下固定的三选一问题——每次必须列出全部三个选项，不得跳过，不得自行默认选择：

“你希望如何处理这些审核结果——(a) 退回：我将此审核意见发布到PR上，由作者修复；(b) 自行修复：我在PR分支上应用修复并推送；(c) 仅聊天：不将任何内容带出本次对话？”

(a) 退回 —— 撰写审核意见草稿，展示给用户，仅在获得批准后发布：
```
gh pr review <n> --request-changes --body-file <draft>
```
（若为非阻塞意见则使用
```
--comment
```
）。
(b) 自行修复 —— 检出PR分支，应用修复，提交并推送到PR头部分支。（跨仓库PR：仅当“维护者可编辑”开启时才可执行——否则仅提供退回选项。）
(c) 仅聊天 —— 不将任何内容带出本次对话。

在用户做出选择前，不得发布、推送、批准或合并PR。若用户已明确表示要合并，需在用户选定处理方式后，单独确认由谁执行合并操作。若scrutinize未发现问题，需报告已完成的追踪内容（不得随意盖章通过），并提供选项：批准（

gh pr review <n> --approve

）或仅聊天。

5. Teardown

5. 清理工作

Restore the original branch (

git switch -

), remove any worktree, delete the temp ref (

git branch -D pr-<n>

). Leave the tree exactly as you found it.

恢复原始分支（

git switch -

），移除所有临时工作区，删除临时引用（

git branch -D pr-<n>

）。让工作区完全恢复到初始状态。

Fork rule — never execute fork code locally

Fork规则——切勿在本地执行Fork代码

You may fetch and READ fork code; you may never RUN it — no test run, no build, no dependency install, no git hooks. And never check it out into your working tree, even detached: watchers, build daemons, and editor tooling execute what lands there. Read via

git show

; if you need file-tool browsing, use a throwaway worktree outside the project — and still run nothing in it. A clean-looking diff is not clearance: anything the test runner imports executes, so scanning manifests or workflows proves nothing. CI (

gh pr checks

) is your only execution evidence; if CI hasn't run, that fact goes in the verdict — your machine is not the substitute.

There is no reviewing task that requires checking a fork out:

git show

plus an outside worktree cover every reading need. If you find yourself typing

checkout

on a fork PR, you are not reading — you are rationalizing.

Excuse	Reality
"I scanned the manifests and workflows first"	Any imported source file executes under the test runner. A scan cannot clear it.
"Checkout only reads files, it doesn't execute"	Your dev tooling executes what appears in the tree. Read via `git show` instead.
"The working tree is clean, so checking the fork branch out is safe"	Clean vs dirty protects your WIP, not you. The hazard is untrusted content inside the project tree — language servers, watchers, and build daemons act on it. Use `git show` or an outside worktree.
"I'll detach onto FETCH_HEAD and browse with Read/Grep — tools, not execution"	The danger is what lands in the tree, not which tool reads it. Watchers and build daemons act on materialized files. `git show` reads without materializing; a worktree outside the project browses without exposing it to project tooling.
"Small diff, known contributor"	Trust is the user's call after the review, not yours before it.
"CI hasn't run, so I'll run the tests myself"	Report "CI pending" as a finding. That is the honest verdict.
"I'll ask the user for permission to run it"	Don't offer. Deliver the static review; execution stays in CI.

你可以拉取并查看Fork代码，但绝对不能运行——禁止测试、构建、安装依赖或执行Git钩子。也禁止将其检出到你的工作区，即使是分离头指针状态：文件监视器、构建守护进程和编辑器工具会自动执行工作区中的代码。通过

git show

查看代码；若需要使用文件工具浏览，可在项目外部使用临时工作区——且仍不得在其中执行任何命令。看似干净的差异不代表安全：测试运行器导入的任何源文件都会被执行，因此扫描清单或工作流无法确保安全。CI（

gh pr checks

）是唯一的执行验证依据；若CI未运行，需将此情况纳入审核结论——本机不能替代CI。

没有任何审核任务需要检出Fork代码：

git show

加外部工作区可满足所有查看需求。如果你发现自己在针对Fork PR执行

checkout

命令，说明你并非在查看代码——而是在找借口违规。

借口	实际情况
“我先扫描了清单和工作流”	任何被导入的源文件都会在测试运行器下执行，扫描无法确保安全。
“检出仅读取文件，不会执行”	你的开发工具会自动执行工作区中的代码，改用 `git show` 查看。
“工作区是干净的，所以检出Fork分支是安全的”	工作区干净与否仅保护你的WIP，无法保护你。风险来自项目工作区中的不可信内容——语言服务器、监视器和构建守护进程会对其进行操作。使用 `git show` 或外部工作区。
“我会分离到FETCH_HEAD，用读/搜索工具浏览——只查看不执行”	风险在于工作区中的文件，而非使用哪个工具查看。监视器和构建守护进程会对实体化的文件进行操作。 `git show` 无需实体化即可读取；项目外部的工作区可浏览文件且不会暴露给项目工具。
“差异很小，贡献者是已知的”	是否信任是用户在审核后的决定，而非你审核前的判断。
“CI未运行，所以我自己运行测试”	将“CI待执行”作为审核结果报告，这才是诚实的结论。
“我会询问用户是否允许运行”	请勿提供此选项。仅提供静态审核结果；执行操作仅在CI中进行。

Red flags — stop and re-read the workflow

警示信号——停止操作并重新阅读工作流程

Ending the review without asking send-back / fix-it / chat-only.
Asking only "should I post this?" — the disposition question includes fix it every time.
Reaching for
```
git stash
```
to make room for a checkout.

git switch --detach FETCH_HEAD

git checkout pr-<n>

, or

gh pr checkout

on a fork PR — even "just to browse".

git show

is the reading path.

Any command that would execute fork code.
```
gh pr review
```
/
```
gh pr merge
```
without an explicit user pick in step 4.

未询问退回/自行修复/仅聊天选项就结束审核。
仅询问“是否发布此审核意见？”——处理方式问题必须每次都包含自行修复选项。
试图使用
```
git stash
```
为检出腾出空间。
针对Fork PR执行
```
git switch --detach FETCH_HEAD
```
、
```
git checkout pr-<n>
```
或
```
gh pr checkout
```
——即使是“仅浏览”。查看代码请使用
```
git show
```
。
任何会执行Fork代码的命令。
未在步骤4获得用户明确选择就执行
```
gh pr review
```
/
```
gh pr merge
```
。