快速开始
npx skills add mattpocock/skills --skill=code-reviewnpx skills update code-review功能说明
code-review 沿着两个独立的维度对 HEAD 与您提供的固定点（一个提交、分支、标签或合并基点）之间的差异进行评审：规范标准（Standards）（代码是否遵循本仓库记录的约定？）和规格符合度（Spec）（代码是否实现了源问题或规格说明所要求的内容？）。它会将每个维度作为独立的并行子智能体运行，并并排报告结果。它永远不会合并或重新排序这两组发现——保持它们分离正是关键所在，因为一项变更可能通过一个维度而在另一个维度上失败，单一的混合结论会让一个掩盖另一个。
何时使用
输入 /code-review，或者当您要求评审一个分支、PR、进行中的变更或任何"自 X 以来"的内容时，智能体会自动调用它。
当有一个差异需要对照已知的良好基准点进行评判，并且您希望两个问题——构建得正确吗？和构建的是正确的东西吗？——被独立回答时，使用此技能。它在构建循环的末尾运行；对于实际以测试优先方式编写代码，请使用 tdd；对于将整个规格说明构建为代码，请使用 implement，后者在提交之前会运行自己的 /code-review 评审。
前置条件
规格符合度（Spec） 维度需要找到源规格说明的位置——提交消息中的问题引用、您传入的路径，或 docs//specs/ 下的规格说明。该问题追踪器的接线来自 setup-matt-pocock-skills；如果没有规格说明，Spec 维度会直接跳过并说明原因。规范标准（Standards） 维度不需要任何设置——即使在一个没有记录任何约定的仓库中，它也始终携带一个内置的 Fowler 代码坏味基线。
两个维度，永不合并
其定义性理念是两个维度。规范标准（Standards） 询问差异是否符合此仓库编写代码的方式——其 CODING_STANDARDS.md 或 CONTRIBUTING.md，加上约 12 种 Fowler 代码坏味的固定基线（神秘命名、重复代码、依恋情结、数据泥团……）。两条规则确保基线安全：有文档记录的仓库标准始终覆盖它，并且每个坏味都是一个判断性调用，而非硬性违规。规格符合度（Spec） 问的是正交的问题——代码是否真正实现了问题或规格说明所要求的，没有遗漏需求或夹带范围蔓延？
它们作为并行的子智能体运行，这样两者就不会污染对方的上下文，最终报告会在单独的 ## Standards 和 ## Spec 标题下呈现它们，并附有每个维度的摘要。故意不设跨维度的单一胜者。
成功的标志
- 它首先确定并确认固定点（
git rev-parse），在错误的引用或空差异上快速失败，而不是在子智能体内部失败。
- Standards 和 Spec 的发现以两个不同的区块呈现，每个区块都引用其来源——一个是仓库标准或基线坏味，另一个是引用的规格说明行。
- 当找不到规格说明时，Spec 维度会报告"无可用规格说明"，而不是凭空捏造需求。
在整个流程中的位置
code-review 是主构建链末尾的评审步骤：
grill-with-docs → to-spec → to-tickets → implement → code-review它最接近的相邻技能是 implement，后者驱动构建并在提交之前将其作为自己的评审过程调用；在上游，它所对照的规格说明由 to-spec 和 to-tickets 生成。当您不确定哪个技能或流程适合时，可以找 ask-matt 帮您导航。