review-order

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review Order

审查顺序

Arguments

参数

Raw arguments: $ARGUMENTS

Parse the arguments as the base branch to diff against. If empty, default to

main

原始参数：$ARGUMENTS

将参数解析为对比差异的基准分支。若为空，默认使用

main

分支。

Goal

目标

Produce a scannable map of the changes between the base branch and

HEAD

, grouped by feature and following the four-pass review order (Types → Data Flow → Business Logic → Edge Cases) within each feature.

The user is going to read this map, then jump into the code themselves. So every bullet needs a

file:line

so they can click straight in. Keep prose minimal — one short clause per bullet. Think index, not essay.

Do not perform the review. Do not make suggestions. Do not flag things to verify, confirm, double-check, or consider. Do not propose tests, fixes, or improvements. Do not ask "is this intended?" or "is this safe?".

Your job is purely descriptive: name the types, point at where data flows, state what the logic does, and point at where edge-case surfaces live. The user reads the map and decides for themselves what to check.

生成基准分支与

HEAD

之间变更的易浏览图谱，按功能分组，并在每个功能内遵循四步审查顺序（Types → Data Flow → Business Logic → Edge Cases）。

用户将阅读此图谱，然后自行查看代码。因此每个项目都需要标注

file:line

，方便用户直接点击跳转。尽量精简文字——每个项目仅用短句描述。将其视为索引，而非随笔。

请勿执行审查操作。请勿提出建议。请勿标记需要验证、确认、复查或考虑的内容。请勿提议测试、修复或改进方案。请勿询问「这是预期的吗？」或「这安全吗？」。

你的工作仅为描述性内容：明确类型、指出数据流位置、说明逻辑功能，并标注边缘场景出现的位置。由用户自行判断需要检查的内容。

The review order (why this structure)

审查顺序（为何采用此结构）

Most people read diffs top to bottom. That misses things. The user reads in this order within each feature:

Types and interfaces first. Describe the data shapes the code expects and produces.
Data flow second. Trace where data comes in, gets transformed, and goes out.
Business logic third. State what the code does — methods, guards, branches.
Edge cases last. Point at the locations where edge-case surfaces exist (branches, nullable values, external input, concurrent paths, queue-context assumptions). Just the location and what makes it an edge-case surface. No advice.

Your job is to make this order easy to follow per feature, not to mash everything into four global buckets.

大多数人会从上到下阅读代码差异，但这样会遗漏内容。用户需在每个功能内按以下顺序阅读：

先看类型与接口：描述代码预期和生成的数据结构。
再看数据流：追踪数据的来源、转换过程和输出去向。
接着看业务逻辑：说明代码的具体功能——方法、守卫、分支逻辑。
最后看边缘场景：指出边缘场景出现的位置（分支、可空值、外部输入、并发路径、队列上下文假设）。仅标注位置和导致边缘场景的原因，无需提供建议。

你的任务是让每个功能内的审查顺序清晰易遵循，而非将所有内容强行归入四个全局类别。

Instructions

操作步骤

1. Get the diff

1. 获取代码差异

Run

git diff <base>...HEAD

(three-dot — i.e. changes on this branch since it diverged) to see what's changed. Also run

git diff --name-status <base>...HEAD

for a quick file-level overview. If there are no changes, tell the user and stop.

执行

git diff <base>...HEAD

（三个点——即该分支从基准分支分叉后的所有变更）查看具体变更内容。同时执行

git diff --name-status <base>...HEAD

快速概览文件级别的变更。若无变更，告知用户并停止操作。

2. Read the changed files

2. 阅读变更文件

For every changed file, read enough of the file (and surrounding files only when needed to understand a data flow) to categorise it.

Skip auto-generated files unless they contain something unexpected:

Lockfiles (

composer.lock

package-lock.json

pnpm-lock.yaml

, etc.)

Compiled assets (
```
public/build/
```
,
```
dist/
```
)
Generated route/type definitions (e.g. Wayfinder action/route files, generated TS types)

对于每个变更文件，阅读足够内容（仅在理解数据流需要时查看周边文件）以进行分类。

忽略自动生成的文件，除非其中包含意外内容：

锁文件（

composer.lock

、

package-lock.json

、

pnpm-lock.yaml

等）

编译资源（
```
public/build/
```
、
```
dist/
```
）
生成的路由/类型定义（如Wayfinder动作/路由文件、生成的TS类型）

3. Identify the feature changes

3. 识别功能变更

Group the diff into the distinct user-facing or behavioural changes the branch introduces. A feature is a coherent unit of behaviour, not a file or a layer. Examples of how to split:

"Unsubscribe via signed link" — controller, route, blade unsubscribe-CTA, page, tests
"Auto-subscribe on idea creation" — observer hook, migration relationship usage, test
"Notify subscribers on status change" — observer, notification class, mail template, tests

Heuristics for identifying features:

A new model/migration usually anchors at least one feature (the thing it represents).
A new route + controller + page is almost always one feature.
A new notification class + its trigger (observer/event) + its mail template is one feature.
Side-effects added to existing flows (e.g. "voting now also subscribes you") are their own small feature.
Pure refactors with no behavioural change can be grouped as a single "Refactor" feature at the end.

If the branch is genuinely a single feature, emit one feature heading. Don't force a split.

将差异内容按分支引入的独立用户可见或行为变更分组。一个功能是一组连贯的行为单元，而非单个文件或层级。拆分示例：

「通过签名链接取消订阅」——控制器、路由、blade取消订阅CTA、页面、测试
「创建想法时自动订阅」——观察者钩子、迁移关系用法、测试
「状态变更时通知订阅者」——观察者、通知类、邮件模板、测试

识别功能的启发式规则：

新模型/迁移通常对应至少一个功能（它所代表的业务对象）。
新路由+控制器+页面几乎总是一个独立功能。
新通知类+触发逻辑（观察者/事件）+邮件模板是一个功能。
为现有流程添加的副作用（如「投票现在同时触发订阅」）属于独立的小型功能。
无行为变更的纯重构可合并为最后一个「重构」功能。

若分支确实仅包含单个功能，只需输出一个功能标题，无需强行拆分。

4. Output the map

4. 输出图谱

Return only the markdown document. No preamble, no summary at the end. Order features roughly by importance / blast radius (auth/security first, refactors last).

Voice. Bullets, not paragraphs. Each bullet is

path/to/file.ext:LINE — short clause

. The clause names what's there in plain words; the

file:line

is what the user clicks. One line per bullet. No multi-sentence explanations. Think

git grep

output with a human-readable suffix, not a code review.

Use this structure:

undefined

仅返回Markdown文档。无需前言，无需结尾总结。按重要性/影响范围排序功能（安全/权限相关优先，重构最后）。

表述风格：使用项目符号，而非段落。每个项目格式为

path/to/file.ext:LINE — 短句描述

。描述部分用直白语言说明内容；

file:line

是用户点击跳转的入口。每行一个项目，无多句解释。可将其视为带可读后缀的

git grep

输出，而非代码审查报告。

使用以下结构：

undefined

Feature: [short name of the change]

Feature: [变更的简短名称]

One sentence describing what behaviour this introduces or changes.

一句话描述此功能引入或修改的行为。

1. Types & Interfaces

```
path/file.php:12
```
— what's there (e.g. "new
```
subscribers
```
BelongsToMany on
```
Idea
```
")

path/migration.php:14

—

idea_subscribers

table, unique on

(idea_id, user_id)

```
path/file.php:12
```
— 内容说明（如「新增
```
Idea
```
模型的
```
subscribers
```
BelongsToMany关联」）

path/migration.php:14

—

idea_subscribers

表，

(idea_id, user_id)

字段唯一

2. Data Flow

```
path/controller.php:23
```
— entry:
```
POST /x
```
→ invokable
```
path/observer.php:18
```
— fan-out: queries subscribers, dispatches notification
```
path/notification.php:30
```
— exit: queued mail via
```
mail.foo
```
template

```
path/controller.php:23
```
— 入口：
```
POST /x
```
→ 可调用方法
```
path/observer.php:18
```
— 分发：查询订阅者，触发通知
```
path/notification.php:30
```
— 出口：通过
```
mail.foo
```
模板发送队列邮件

3. Business Logic

```
path/observer.php:22
```
— short-circuit on
```
is_internal
```
```
path/observer.php:28
```
— actor-exclusion gate
```
path/controller.php:14
```
—
```
detach
```
runs unconditionally on bound pair

```
path/observer.php:22
```
— 当
```
is_internal
```
为真时短路执行
```
path/observer.php:28
```
— 排除触发者的守卫逻辑
```
path/controller.php:14
```
— 绑定对的
```
detach
```
操作无条件执行

4. Edge Cases

```
path/observer.php:25
```
—
```
Auth::id()
```
is null in queue/console contexts
```
path/controller.php:14
```
— public route, no auth check, signed URL has no expiry

```
path/observer.php:25
```
— 队列/控制台上下文时
```
Auth::id()
```
为空
```
path/controller.php:14
```
— 公开路由，无权限校验，签名URL无过期时间

Feature: [next change]

Feature: [下一个变更]

...


Omit a section if there's nothing meaningful in it. A small feature might be just Logic + Edges.

...


若某部分无有意义内容则省略。小型功能可能仅包含Logic + Edges部分。

Rules

规则

Every bullet has a
file:line
. That's the whole point — the user clicks it to jump. No bullet without a citation. If you genuinely need to say something that has no specific line (a feature-level note), put it in the one-sentence intro under the feature heading, not in the bullets.
One short clause per bullet. Aim for under ~15 words after the em-dash. If you need more, you're writing a review, not a map. Split into two bullets at different lines, or cut.
No suggestions, no advice, no questions. Banned phrasings: "verify that…", "confirm…", "make sure…", "consider…", "check whether…", "is this intended?", "is this safe?", "should we…", "could…", "might want to…". State facts only.
No emojis. If something is security-sensitive, say so in words in the feature intro — don't decorate.
Description over prescription. "
```
detach
```
runs unconditionally on the bound pair" is fine. "Confirm it's safe that
```
detach
```
runs unconditionally" is not.
Edge Cases name the surface, not the fix. Nullable input, unguarded branch, external state, queue-context assumption, concurrent path. Don't tell the reviewer what to do about it.
Group by feature, not by review pass. The four passes go inside each feature, in order, every time.
Omit a pass within a feature if nothing fits it. Don't pad with filler.
Skip auto-generated files (lockfiles, compiled assets, generated route/type definitions) unless they contain something unexpected.
Order features by blast radius: security/auth-sensitive first, user-facing behaviour next, internal/refactor last. Flag the sensitive surface in the feature intro sentence.
A file can appear under multiple features (e.g. a controller that gained two unrelated endpoints). Within one feature, a given line should only appear once — pick the most useful pass for it.

每个项目必须包含
file:line
：这是核心价值——方便用户点击跳转。无引用的项目不得出现。若确实需要说明无特定行的内容（功能级备注），请放在功能标题下的一句话介绍中，而非项目符号里。
每个项目仅用短句描述：破折号后的内容控制在约15词以内。若需要更多内容，说明你在写审查报告而非图谱。拆分为不同行的两个项目，或精简内容。
禁止建议、指导或提问：禁用表述：「请验证…」「确认…」「确保…」「考虑…」「检查是否…」「这是预期的吗？」「这安全吗？」「我们应该…」「可以…」「可能需要…」。仅陈述事实。
禁止使用表情符号：若内容涉及安全敏感，在功能介绍的一句话中用文字说明——不要添加装饰。
描述优先于建议：「绑定对的
```
detach
```
操作无条件执行」是合规的。「请确认
```
detach
```
无条件执行是否安全」不合规。
边缘场景仅标注场景本身，而非修复方案：可空输入、无守卫分支、外部状态、队列上下文假设、并发路径。无需告诉审查者如何处理。
按功能分组，而非按审查步骤：四步审查顺序需在每个功能内依次执行。
若功能内无对应内容，可省略该审查步骤：请勿填充无关内容。
忽略自动生成的文件（锁文件、编译资源、生成的路由/类型定义），除非其中包含意外内容。
按影响范围排序功能：安全/权限敏感内容优先，用户可见行为次之，内部/重构最后。在功能介绍的一句话中标注敏感场景。
一个文件可出现在多个功能下（如新增两个无关端点的控制器）。在单个功能内，同一行仅需出现一次——选择最适合的审查步骤放置。