把一段已提交的 Git 变更分别对照项目规范和需求说明，找出两类偏差。
安装与准备
在项目目录的终端执行以下命令，安装后在 Claude Code 中输入下方提示。这里选择项目内的可编辑文件安装。
npx skills@latest add mattpocock/skills --skill code-review --skill setup-matt-pocock-skills --agent claude-code
使用 Codex 时，把安装命令最后的 claude-code 换成 codex，对话里把 /code-review 换成 $code-review。如果使用完整的 Claude Code 插件，则选择 /mattpocock-skills:code-review，不要再重复安装文件版本。
准备一个有效基准分支或提交、需求文档和项目规范。工程工作流首次使用时运行 setup-matt-pocock-skills，配置问题跟踪器；纯本地项目可以选择本地文件。
第一次使用
把下面的场景和路径替换成你的项目情况，在 Agent 对话里输入：
/code-review main
需求在 specs/export.md。分别检查规范和需求实现；重点看空结果导出、字段顺序和错误提示。请让两位审查者直接审查，不继续委派。
怎样推进任务
确认比较范围
先查看基准是否存在，以及 main 到 HEAD 的共同祖先之后有哪些变化。该 Skill 使用三点比较；如果导出功能还没提交，先把要审查的修改整理成提交，才能进入比较。不要把空 diff 理解成代码全部正确。
分开阅读两份结论
Standards 部分检查仓库约定，并区分明确规则和需要判断的设计问题；Spec 部分查缺失需求、额外范围和错误实现。导出字段顺序正确但违反团队接口约定，可能只出现在前一部分；遗漏空状态处理，则应回到需求条目。
逐项复核后再修改
打开每条问题引用的文件和需求原句，确认是否适用于当前变更。先修会改变用户行为的问题，再处理有明确理由的规范偏差。把纯风格偏好留给团队判断，无须反复运行直到任何建议都不再出现。
完成后检查什么
你应能看到 Standards 和 Spec 两部分，每条建议有规则或需求依据。为接受的修复运行相关检查；无需求文档时应明确缺少 Spec 审查，不能把规范通过当作需求通过。
常见问题
看不到刚改的代码？ 默认范围是 <base>...HEAD，不包含工作区或暂存区。
调用了另一个同名命令？ 确认选择的是 mattpocock 的 Skill；完整插件可用带命名空间的调用。
报告可以直接作为合并依据吗？ 它提供待复核的问题，不替代测试和人工检查。
什么时候该换一种审查方式
这项 Skill 检查的是一段变更是否符合项目规则，以及是否实现了原先决定的需求。若你只想寻找空值、竞态或越界等代码缺陷，应另外安排针对缺陷的审查；若还没有变更可读，则应先完成实现。启动前给出一个确定的基准提交或分支，并确认从基准到当前提交确有 diff。基准拼错或范围为空时，先修正比较范围，不要把空报告当成通过。
Claude Code 也有名为 code-review 的内置命令，功能并不相同。插件安装方式下可用带 mattpocock-skills 命名空间的名称确认调用对象；文件安装方式可能遮住内置同名命令。两份结论回来后，分别打开所引用的规范、需求和代码位置；没有需求文档时，只能完成规范轴，不能凭审查者推测出一份规格。修复接受的问题后，运行相关测试，再核对这次 diff 是否仍符合原来的范围。
换一个场景：检查价格计算分支
如果本次变更是“会员订单在优惠后仍达到免运费门槛”，先把规则写在 specs/shipping.md，并确认计算代码已经提交。可以这样输入：“请用 code-review 对比 main 与当前 HEAD；需求在 specs/shipping.md，重点核对免运费门槛看的是优惠前还是优惠后金额，并分开报告仓库规范与需求偏差。”先检查两份报告是否分别引用规范文件、规格原句和实际 diff，再决定是否改代码。
若报告没有 Spec 部分，先查规格路径与跟踪器配置，而不是把 Standards 通过当作需求通过。若根本看不到刚写的运费逻辑，检查修改是否仍在工作区，因为此 Skill 的三点比较只读已提交变更。看到“可能不符合惯例”的意见时，点开引用位置验证；模糊推测不能代替真实规则。
把审查意见当作待验证线索
一项针对同一个大型 Angular PR 的对照试验中，这个 Skill 提出了其他审查流程没提到的三个问题，也多报了几条泛泛的代码气味；作者尚未逐条核对这些发现是否真实。使用时先让它给每条意见指出代码位置、对应规范或需求，再由人查看 diff 和运行必要测试。对大 PR 可以挑关键模块复审，别把“发现数量更多”直接等同于质量更高。