---
name: review
description: 审查从固定点（提交、分支、标签或合并基）以来的变更，沿两个维度——标准（代码是否遵循此仓库记录在案的编码标准？）和规格（代码是否匹配原始问题/PRD 所要求的？）。在两个并行子代理中运行两个审查，并将它们并排报告。当用户想要审查分支、PR、进行中的变更，或要求"审查从 X 以来"时使用。
---

# Review

对 `HEAD` 和用户提供的固定点之间的差异进行双维度审查：

- **标准** — 代码是否符合此仓库记录在案的编码标准？
- **规格** — 代码是否忠实地实现了原始问题 / PRD / 规格？

两个维度作为**并行子代理**运行，因此它们不会污染彼此的上下文，然后本技能汇总它们的发现。

问题跟踪器应该已提供给你——如果 `docs/agents/issue-tracker.md` 缺失，运行 `/setup-matt-pocock-skills`。

## 流程

### 1. 确定固定点

用户所说的任何内容就是固定点——提交 SHA、分支名称、标签、`main`、`HEAD~5` 等。不要有主见；原样传递。如果他们没有指定，询问："审查相对于什么——分支、提交还是 `main`？" 直到你得到答案才继续。

捕获差异命令一次：`git diff <fixed-point>...HEAD`（三点，因此比较是针对合并基的）。同时通过 `git log <fixed-point>..HEAD --oneline` 记录提交列表。

### 2. 识别规格来源

按以下顺序查找原始规格：

1. 提交消息中的问题引用（`#123`、`Closes #45`、GitLab `!67` 等）——通过 `docs/agents/issue-tracker.md` 中的工作流获取。
2. 用户作为参数传递的路径。
3. `docs/`、`specs/` 或 `.scratch/` 下与分支名称或功能匹配的 PRD/规格文件。
4. 如果没有找到任何内容，询问用户规格在哪里。如果他们说没有，**规格**子代理将跳过并报告"无可用规格"。

### 3. 识别标准来源

仓库中任何记录应如何编写代码的内容。常见位置：

- `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` 或类似文件

收集文件列表。**标准**子代理将阅读它们。

### 4. 并行生成两个子代理

发送包含两个 `Agent` 工具调用的单个消息。两者都使用 `general-purpose` 子代理。

**标准子代理提示** — 包括：

- 完整的差异命令和提交列表。
- 你在步骤 3 中找到的标准来源文件列表。
- 简要指令："阅读标准文档。然后阅读差异。报告——在相关的每个文件/片段处——差异违反记录在案的标准的每一处。引用标准（文件 + 规则）。区分硬性违规和判断性选择。跳过工具强制执行的内容。400 词以内。"

**规格子代理提示** — 包括：

- 差异命令和提交列表。
- 规格的路径或获取的内容。
- 简要指令："阅读规格。然后阅读差异。报告：(a) 规格要求的但缺失或不完整的需求；(b) 差异中存在但未被要求的行为（范围蔓延）；(c) 看起来已实现但实现方式错误的需求。为每个发现引用规格行。400 词以内。"

如果规格缺失，跳过规格子代理并在最终报告中注明。

### 5. 汇总

在 `## 标准` 和 `## 规格` 标题下呈现两份报告，逐字或经轻微清理。不要合并或重新排序发现——两个维度是故意分开的，以便用户能独立查看它们。

以一行摘要结束：每个维度的发现总数，以及（如果有）被标记的最严重的单个问题。

## 为什么是两个维度

一个变更可以通过一个维度但未通过另一个：

- 代码遵循所有标准但实现了错误的内容 → **标准通过，规格失败。**
- 代码完全按照问题要求但违反了项目约定 → **规格通过，标准失败。**

分别报告它们可以防止一个维度掩盖另一个维度。
