review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review

审查

Two-axis review of the diff between

HEAD

and a fixed point the user supplies:

Standards — does the code conform to this repo's documented coding standards?
Spec — does the code faithfully implement the originating issue / PRD / spec?

Both axes run as parallel sub-agents so they don't pollute each other's context, then this skill aggregates their findings.

The issue tracker should have been provided to you — run

/setup-matt-pocock-skills

docs/agents/issue-tracker.md

is missing.

从用户指定的固定节点与

HEAD

之间的代码差异，进行双维度审查：

标准维度 —— 代码是否符合本仓库文档中规定的编码标准？
规格维度 —— 代码是否忠实地实现了源需求issue / PRD / 规格文档？

两个维度的审查由并行子Agent执行，避免互相干扰上下文，之后由本skill汇总审查结果。

系统应已提供问题追踪器——如果缺少

docs/agents/issue-tracker.md

，请执行

/setup-matt-pocock-skills

。

Process

流程

1. Pin the fixed point

1. 确定固定节点

Whatever the user said is the fixed point — a commit SHA, branch name, tag,

main

HEAD~5

, etc. Don't be opinionated; pass it through. If they didn't specify one, ask: "Review against what — a branch, a commit, or

main

?" Don't proceed until you have it.

Capture the diff command once:

git diff <fixed-point>...HEAD

(three-dot, so the comparison is against the merge-base). Also note the list of commits via

git log <fixed-point>..HEAD --oneline

用户指定的任意内容均可作为固定节点——commit哈希值、分支名、tag、

main

、

HEAD~5

等。无需主观判断，直接使用用户指定的内容。如果用户未指定，请询问：“请指定审查基准——分支、commit还是

main

？”在获取到基准前不要继续执行。

一次性记录差异命令：

git diff <fixed-point>...HEAD

（使用三个点，基于合并基准进行对比）。同时通过

git log <fixed-point>..HEAD --oneline

记录提交列表。

2. Identify the spec source

2. 确定规格来源

Look for the originating spec, in this order:

Issue references in the commit messages (
```
#123
```
,
```
Closes #45
```
, GitLab
```
!67
```
, etc.) — fetch via the workflow in
```
docs/agents/issue-tracker.md
```
.
A path the user passed as an argument.
A PRD/spec file under
```
docs/
```
,
```
specs/
```
, or
```
.scratch/
```
matching the branch name or feature.
If nothing is found, ask the user where the spec is. If they say there isn't one, the Spec sub-agent will skip and report "no spec available".

按以下顺序查找源规格文档：

提交信息中的issue引用（如
```
#123
```
、
```
Closes #45
```
、GitLab的
```
!67
```
等）——通过
```
docs/agents/issue-tracker.md
```
中的工作流获取内容。
用户作为参数传入的路径。
位于
```
docs/
```
、
```
specs/
```
或
```
.scratch/
```
目录下，与分支名或功能匹配的PRD/规格文件。
如果未找到任何内容，请询问用户规格文档的位置。如果用户表示不存在规格文档，则规格维度的子Agent将跳过审查，并报告“无可用规格文档”。

3. Identify the standards sources

3. 确定标准来源

Anything in the repo that documents how code should be written. Common locations:

```
CLAUDE.md
```
,
```
AGENTS.md
```
```
CONTRIBUTING.md
```
```
CONTEXT.md
```
,
```
CONTEXT-MAP.md
```
, per-context
```
CONTEXT.md
```
files
```
docs/adr/
```
(architectural decisions are standards)
```
.editorconfig
```
,
```
eslint.config.*
```
,
```
biome.json
```
,
```
prettier.config.*
```
,
```
tsconfig.json
```
(machine-enforced standards — note them but don't re-check what tooling already checks)
Any
```
STYLE.md
```
,
```
STANDARDS.md
```
,
```
STYLEGUIDE.md
```
, or similar at the repo root or under
```
docs/
```

Collect the list of files. The Standards sub-agent will read them.

仓库中所有记录代码编写规范的文档。常见位置包括：

```
CLAUDE.md
```
、
```
AGENTS.md
```
```
CONTRIBUTING.md
```
```
CONTEXT.md
```
、
```
CONTEXT-MAP.md
```
、各上下文对应的
```
CONTEXT.md
```
文件
```
docs/adr/
```
（架构决策属于标准范畴）
```
.editorconfig
```
、
```
eslint.config.*
```
、
```
biome.json
```
、
```
prettier.config.*
```
、
```
tsconfig.json
```
（机器强制执行的标准——只需记录，无需重复检查工具已覆盖的内容）
仓库根目录或
```
docs/
```
目录下的任何
```
STYLE.md
```
、
```
STANDARDS.md
```
、
```
STYLEGUIDE.md
```
或类似文件

收集这些文件列表，标准维度的子Agent将读取这些文件。

4. Spawn both sub-agents in parallel

4. 并行启动两个子Agent

Send a single message with two

Agent

tool calls. Use the

general-purpose

subagent for both.

Standards sub-agent prompt — include:

The full diff command and commit list.
The list of standards-source files you found in step 3.
The brief: "Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Under 400 words."

Spec sub-agent prompt — include:

The diff command and commit list.
The path or fetched contents of the spec.
The brief: "Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."

If the spec is missing, skip the Spec sub-agent and note this in the final report.

发送一条包含两个

Agent

工具调用的消息。两者均使用

general-purpose

子Agent。

标准子Agent提示词——需包含：

完整的差异命令和提交列表。
步骤3中找到的标准源文件列表。
任务说明：“阅读标准文档，然后查看代码差异。针对相关的每个文件/代码块，报告所有差异违反文档标准的地方。引用对应的标准（文件+规则）。区分硬性违规和主观判断项。跳过工具已强制执行的内容。字数控制在400字以内。”

规格子Agent提示词——需包含：

差异命令和提交列表。
规格文档的路径或获取到的内容。
任务说明：“阅读规格文档，然后查看代码差异。报告：(a) 规格文档要求但未实现或部分实现的需求；(b) 代码差异中存在但规格未要求的内容（范围蔓延）；(c) 看起来已实现但存在错误的需求。每项发现需引用规格文档的对应行。字数控制在400字以内。”

如果缺少规格文档，则跳过规格子Agent，并在最终报告中注明这一点。

5. Aggregate

5. 汇总结果

Present the two reports under

## Standards

and

## Spec

headings, verbatim or lightly cleaned. Do not merge or rerank findings — the two axes are deliberately separate so the user can see them independently.

End with a one-line summary: total findings per axis, and the worst single issue (if any) flagged.

将两份报告分别放在

## 标准维度

和

## 规格维度

标题下，原文呈现或稍作整理。不要合并或重新排序审查结果——两个维度故意分开，以便用户独立查看。

最后添加一行总结：每个维度的总问题数，以及（如果有）最严重的单个问题。

Why two axes

为什么采用双维度审查

A change can pass one axis and fail the other:

Code that follows every standard but implements the wrong thing → Standards pass, Spec fail.
Code that does exactly what the issue asked but breaks the project's conventions → Spec pass, Standards fail.

Reporting them separately stops one axis from masking the other.

代码变更可能通过其中一个维度但未通过另一个：

完全符合标准但实现了错误功能的代码 → 标准维度通过，规格维度未通过。
完全符合issue要求但违反项目约定的代码 → 规格维度通过，标准维度未通过。

分开报告可避免一个维度的结果掩盖另一个维度的问题。