review

评审

对比 HEAD 与用户指定固定点的双维度评审：

• 标准 — 代码是否符合此仓库记录的编码标准？
• 规格 — 代码是否忠实实现了原始 issue／PRD／规格说明？

两个维度会由并行子 Agent分别执行，以避免彼此的上下文受到干扰，然后由此技能汇总结果。

Issue 跟踪工具应该已提供给你——如果缺少 docs/agents/issue-tracker.md，请运行 /setup-matt-pocock-skills。

流程

1. 确定固定点

用户指定的内容就是固定点——commit SHA、分支名称、标签、main、HEAD~5 等。不要自行判断；直接传入。如果用户没有指定，请询问：“要对照什么进行评审——分支、commit，还是 main？”在获得固定点之前不要继续。

记录一次 diff 命令：git diff <fixed-point>...HEAD（三个点，因此比较的是 merge-base）。同时记录 commit 列表：git log <fixed-point>..HEAD --oneline。

2. 确定规格来源

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

1. commit 消息中的 issue 引用（#123、Closes #45、GitLab !67 等）——通过 docs/agents/issue-tracker.md 中的工作流获取。
2. 用户作为参数传入的路径。
3. docs/、specs/ 或 .scratch/ 下与分支名称或功能匹配的 PRD／规格文件。
4. 如果没有找到，请询问用户规格在哪里。如果用户表示没有规格，规格子 Agent 将跳过评审并报告“没有可用的规格”。

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

收集文件列表。标准子 Agent 将阅读这些文件。

4. 并行启动两个子 Agent

发送一条消息，其中包含两个 Agent 工具调用。两者都使用 general-purpose 子 Agent。

标准子 Agent 提示——包含：

• 完整的 diff 命令和 commit 列表。
• 第 3 步找到的标准来源文件列表。
• 任务说明：“阅读标准文档，然后阅读 diff。逐个文件／相关代码段报告 diff 中每一处违反已记录标准的地方。引用标准（文件＋规则）。区分明确违规与判断性意见。跳过工具强制执行的内容。少于 400 词。”

规格子 Agent 提示——包含：

• diff 命令和 commit 列表。
• 规格路径或获取到的规格内容。
• 任务说明：“阅读规格，然后阅读 diff。报告：(a) 规格要求但缺失或只部分实现的内容；(b) diff 中未要求的行为（范围蔓延）；(c) 看似已实现、但实现可能有误的要求。每项发现都引用规格原文。少于 400 词。”

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

5. 汇总

分别在 ## 标准 和 ## 规格 标题下呈现两份报告，原样保留或稍作整理。不要合并或重新排序发现——这两个维度特意分开，以便用户分别查看。

最后用一行总结：各维度的发现总数，以及标记出的最严重问题（如有）。

为什么要分两个维度

一项更改可能通过一个维度，却未通过另一个维度：

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

分开报告可以避免一个维度掩盖另一个维度。