Code Review
从固定点（commit、branch、tag 或 merge-base）开始，按 Standards（代码是否符合本仓库记录的编码标准？）和 Spec（代码是否符合来源...
Install
npx skills add vinvcn/mattpocock-skills-zh-CN --skill code-review -g -a claude-code -y- Repository
- vinvcn/mattpocock-skills-zh-CN5.5k
- Category
- Git and review
- Updated
- 7d ago
- License
- MIT
- Context cost
- Lightabout 997 tokens
- Runs scripts
- No, instructions only
What it does
从固定点（commit、branch、tag 或 merge-base）开始，按 Standards（代码是否符合本仓库记录的编码标准？）和 Spec（代码是否符合来源 issue/spec 的要求？）两个轴线审查变更。两个审查会在并行子代理中运行，并并排报告。适用于用户想审查 branch、PR、进行中的变更，或要求“review since X”时。
对用户提供的 fixed point 与 HEAD 之间的 diff 做双轴 review：
- Standards：代码是否符合这个 repo 记录下来的 coding standards？
- Spec：代码是否忠实实现来源 issue / spec？
两个轴线都作为并行 sub-agents运行，避免互相污染 context；然后这个 skill 聚合它们的 findings。
Issue tracker 应该已经提供给你；如果没有，请让用户运行 /setup-matt-pocock-skills。
流程
1. 确定 fixed point
用户说的任何内容都是 fixed point：commit SHA、branch name、tag、main、HEAD~5 等。如果用户没有指定，就询问。
先捕获一次 diff command：git diff <fixed-point>...HEAD（three-dot，因此比较对象是 merge-base）。同时用 git log <fixed-point>..HEAD --oneline 记录 commits 列表。
继续前，确认 fixed point 能解析（git rev-parse <fixed-point>），并且 diff 非空。错误 ref 或空 diff 应该在这里失败，而不是进入两个并行 sub-agents 后才失败。
2. 找到 spec 来源
按以下顺序寻找来源 spec：
- Commit messages 中的 issue references（
#123、Closes #45、GitLab!67等），按 tracker doc 中的 workflow 获取。 - 用户作为 argument 传入的 path。
docs/、specs/或.scratch/下与 branch name 或 feature 匹配的 spec 文件。- 如果什么都找不到，询问用户 spec 在哪里。如果用户说没有 spec，Spec sub-agent 跳过并报告 “no spec available”。
3. 找到 standards 来源
搜索 repo 中所有记录代码应该如何写的文件。当 CODING_STANDARDS.md 或 CONTRIBUTING.md 存在时，必须列入清单。
在 repo 自己记录的 standards 之外，Standards 轴线始终带有下面的 smell baseline：一组固定的 Fowler code smells（Refactoring 第 3 章），即使 repo 没有任何约定也适用。有两条规则：
- The repo overrides. 已记录的 repo standard 永远优先；如果它认可 baseline 会标记的东西，就压制该 smell。
- Always a judgement call. 每个 smell 都是带 label 的 heuristic（例如 "possible Feature Envy"），不是硬性违规；和这里的其他 standard 一样，跳过 tooling 已经强制检查的内容。
每个 smell 按 what it is -> how to fix 读取，并对照 diff：
