# Code Review

从固定点（commit、branch、tag 或 merge-base）开始，沿两条轴线审查变更, , 规范（代码是否遵循仓库文档化的编码规范？）和规格（代码是否与原始...

- Repository: https://github.com/devcxl/mattpocock-skills-zh (522 stars)
- Category: AI and agents
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add devcxl/mattpocock-skills-zh --skill code-review -g -a claude-code -y`
Codex: `npx skills add devcxl/mattpocock-skills-zh --skill code-review -g -a codex -y`
Cursor: `npx skills add devcxl/mattpocock-skills-zh --skill code-review -g -a cursor -y`
Gemini CLI: `npx skills add devcxl/mattpocock-skills-zh --skill code-review -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add devcxl/mattpocock-skills-zh`

## Description

从固定点（commit、branch、tag 或 merge-base）开始，沿两条轴线审查变更, , 规范（代码是否遵循仓库文档化的编码规范？）和规格（代码是否与原始 issue/PRD 的要求一致？）。两条审查线在并行子 agent 中运行，并以并排方式报告结果。当用户想审查一个分支、PR、进行中的变更，或要求"从 X 开始审查"时使用。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 审查

对 `HEAD` 与用户指定的固定点之间的 diff 进行双轴审查：

- **规范**, , 代码是否符合本仓库文档化的编码规范？
- **规格**, , 代码是否忠实地实现了原始 issue / PRD / 规格？

两条轴线作为**并行子 agent** 运行，互不污染彼此的上下文，然后由本技能汇总双方的发现。启动每个子 agent 时，都使用全新的上下文窗口。

Issue 跟踪器应该已经提供给你了。如果没有，请告诉用户运行 `/setup-matt-pocock-skills`。

## 流程

### 1. 确定固定点

用户说的任何东西都可以作为固定点, , commit SHA、分支名、tag、`main`、`HEAD~5` 等等。不要随意发挥，直接传入即可。如果用户没有指定，则询问："以什么为基准进行审查, , 一个分支、一个 commit、还是 `main`？" 没有得到答案之前不要继续。

捕获 diff 命令：`git diff <fixed-point>...HEAD`（三个点，这样比较的是 merge-base）。同时通过 `git log <fixed-point>..HEAD --oneline` 记录 commit 列表。

在继续之前，确认固定点能解析（`git rev-parse <fixed-point>`）且 diff 非空。错误的引用或空的 diff 应该在此处失败, , 不应该让两个并行子 agent 来处理。

### 2. 确定规格来源

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

1. commit 消息中的 issue 引用（`#123`、`Closes #45`、GitLab `!67` 等）, , 按照 tracker 文档中的工作流来获取。
2. 用户作为参数传入的路径。
3. `docs/`、`specs/` 或 `.scratch/` 下与分支名或功能名匹配的 PRD/规格文件。
4. 如果什么都没找到，询问用户规格在哪里。如果用户说没有，**规格**子 agent 将跳过并报告"无可用的规格"。

### 3. 确定规范来源

搜索仓库，找出所有记载代码编写规范的文件。若存在 `CODING_STANDARDS.md` 或 `CONTRIBUTING.md`，必须将它们列入来源。

除了仓库记录的内容外，规范轴线始终携带下面的**气味基线（smell baseline）**, , 一组来自 Fowler《重构》第 3 章的固定代码气味，即使仓库没有任何文档也适用。两条约束规则：

- **仓库覆盖规范。** 已文档化的仓库标准永远优先；如果仓库明确认可了基线的某些判定，则压制该气味。
- **始终是判断性问题。** 每个气味都是带标签的启发式判断（"可能的特性依恋"），绝不是一个硬性违反, , 而且和这里的所有标准一样，跳过工具已强制执行的内容。

每个气味的格式为*它是什么* → *如何修复*；将其与 diff 匹配：

The rest: https://github.com/devcxl/mattpocock-skills-zh/blob/HEAD/skills/engineering/code-review/SKILL.md