review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review

评审

Review the change by running the passes in

passes/

, in order. Each pass is a skill in this directory — read it and apply it.

按顺序执行

passes/

目录下的各个审查环节，对变更进行评审。每个环节都是该目录下的一项skill，请阅读并执行相应操作。

Scope

评审范围

The change is the diff against the merge-base with the base branch (

git diff origin/main...HEAD

, or the base/range the caller gives). Confirm the ref resolves; if the diff is empty, say so and stop. Skip generated and vendored files.

变更内容是与基准分支的merge-base之间的差异（

git diff origin/main...HEAD

，或调用者指定的基准/范围）。确认引用可解析；如果差异为空，请说明并停止评审。跳过自动生成文件和vendored文件。

Step 0 — Find the project's reference material

步骤0 — 查找项目参考资料

Before judging anything, know where this project keeps its decisions and standards.

First, check for a

REVIEW.md

at the repo root (generated by the

document-conventions

skill). If it exists, read it — it's authoritative: it maps each pass to the docs that define "correct" for this project. It's a table of contents written in natural language, so read it as guidance, then read the docs it points to. Use those paths.

If there's no

REVIEW.md

, discover:

Agent instructions. Read the repo's
```
AGENTS.md
```
(or
```
CLAUDE.md
```
) at the root. They usually point at the docs that matter; honor anything they state about conventions.
Documentation. Look for a
```
knowledge/
```
or
```
docs/
```
directory. If there's a
```
knowledge/table-of-contents.md
```
or
```
docs/README.md
```
, read it — it's the index. Otherwise list the directory and read anything that looks like standards.
Conventions. Find the project's stated standards —
```
knowledge/technical/conventions.md
```
,
```
CONTRIBUTING.md
```
,
```
.cursor/rules/
```
, or similar. "Conventions" in the passes below means these, not generic advice.
Stack. Identify the frameworks from
```
composer.json
```
/
```
package.json
```
/
```
Cargo.toml
```
. For each one, apply its conventions pack from the open-review repo (
```
skills/conventions/<name>
```
— e.g.
```
laravel
```
,
```
react
```
,
```
inertia
```
): if the pack is installed locally, read it; otherwise resolve it at runtime (
```
npx skills use elliottlawson/open-review@<name>
```
, or fetch the pack's
```
SKILL.md
```
from GitHub). A pack is that framework's standard — its index routes you to sub-files based on what the change touches; apply the relevant sections at the matching passes. Precedence: this project's documented conventions override packs; packs override general merits.

Missing files are fine — skip them silently. If the project has no documented standards, say so in the verdict instead of inventing any. If you had to discover instead of using a

REVIEW.md

, that's fine — but if the project has conventions and no

REVIEW.md

, mention that the

document-conventions

skill would make future reviews more accurate.

Run: mission → architecture → implementation → craft → security → performance.

Then weigh the passes into a verdict:

Approve — mission met, no blocking findings.
Changes needed — real issues found; name them.
Hold — mission unclear, or an architectural concern needs discussion first.

Depth calibration. Match depth to scope — a 2-file bugfix is brief; a 30-file feature gets deep coverage.

Verify before you flag. A finding must point at a concrete line and a concrete consequence. If you can't verify it, ask a question instead.

Report your findings in prose — severity (critical / warning / info), the pass that found it, the file and line, and why it matters. If you're running under CI, the

review-as-json

skill wraps this review and shapes the output as JSON instead.

在进行任何判断之前，先了解项目的决策和标准存放位置。

首先，检查仓库根目录下是否存在

REVIEW.md

文件（由

document-conventions

skill生成）。如果存在，请阅读该文件——它具有权威性：它将每个审查环节映射到定义本项目“正确”标准的文档。这是一个用自然语言编写的目录，请将其作为指导阅读，然后阅读它指向的文档，并使用这些文档路径。

如果没有

REVIEW.md

，请按以下方式查找：

Agent 说明：阅读仓库根目录下的
```
AGENTS.md
```
（或
```
CLAUDE.md
```
）文件。这些文件通常会指向重要的文档，请遵循其中提到的任何约定。
文档：查找
```
knowledge/
```
或
```
docs/
```
目录。如果存在
```
knowledge/table-of-contents.md
```
或
```
docs/README.md
```
，请阅读它——这是文档索引。否则列出目录内容，阅读所有看起来是标准相关的文件。
约定：查找项目已声明的标准——例如
```
knowledge/technical/conventions.md
```
、
```
CONTRIBUTING.md
```
、
```
.cursor/rules/
```
或类似文件。下文审查环节中提到的“约定”指的是这些文件中的内容，而非通用建议。
技术栈：从
```
composer.json
```
/
```
package.json
```
/
```
Cargo.toml
```
文件中识别使用的框架。对于每个框架，应用open-review仓库中的对应约定包（
```
skills/conventions/<name>
```
——例如
```
laravel
```
、
```
react
```
、
```
inertia
```
）：如果该包已在本地安装，请阅读它；否则在运行时解析（
```
npx skills use elliottlawson/open-review@<name>
```
，或从GitHub获取该包的
```
SKILL.md
```
文件）。约定包包含该框架的标准——其索引会根据变更涉及的内容引导你查看子文件；在对应的审查环节中应用相关部分内容。优先级：项目自身文档化的约定优先于约定包；约定包优先于通用准则。

缺失文件无需处理——直接跳过即可。如果项目没有文档化的标准，请在评审结论中说明，不要自行制定标准。如果无法使用

REVIEW.md

而不得不自行查找资料，这是可以接受的——但如果项目有约定却没有

REVIEW.md

，请提及使用

document-conventions

skill可以让未来的评审更准确。

按以下顺序执行审查环节：任务目标 → 架构 → 实现 → 工艺 → 安全 → 性能。

然后综合各个审查环节的结果给出评审结论：

批准：达成任务目标，无阻塞性问题。
需要修改：发现实际问题；请列出具体问题。
暂缓：任务目标不明确，或存在需要先讨论的架构问题。

深度校准：评审深度需与范围匹配——涉及2个文件的bug修复只需简要评审；涉及30个文件的功能则需要全面深入的评审。

标记前先验证：发现的问题必须指向具体代码行和具体影响。如果无法验证，请以提问方式提出。

用书面形式报告你的发现——包含严重程度（critical / warning / info）、发现问题的审查环节、文件和代码行，以及问题的影响。如果在CI环境中运行，

review-as-json

skill会封装本次评审并将输出格式化为JSON。