# Review

> 沿两个轴审查自固定点（提交、分支、标签或合并基础）以来的更改——标准（代码是否遵循此仓库记录的编码标准？）和规范（代码是否符合原始 issue/PRD 的要求？）。在并行子代理中运行两个审查并并排报告它们。当用户想要审查分支、PR、进行中的更改或要求"审查自 X 以来"时使用。

- Skill: `karasukaigan/review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add karasukaigan/review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/karasukaigan/review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: karasukaigan (https://skillmd.com/u/karasukaigan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/karasukaigan/review

---


# 审查

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

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

两个轴都作为**并行子代理**运行，这样它们不会相互污染上下文，然后此技能聚合它们的发现。

issue tracker 应该已经提供给你——如果 `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. 提交消息中的 issue 引用（`#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. 聚合

在 `## Standards` 和 `## Spec` 标题下展示两个报告，逐字或轻微清理。不要**合并或重新排名发现**——两个轴故意分开，以便用户可以独立看到它们。

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

## 为什么是两个轴

更改可以通过一个轴而失败另一个：

- 遵循每个标准但实现错误内容的代码 → **标准通过，规范失败。**
- 完全按照 issue 要求但破坏项目约定的代码 → **规范通过，标准失败。**

分别报告它们防止一个轴掩盖另一个。