代码审查的关键不在工具，在纪律：先对齐关注点、每个发现都要证据、重要审查在干净上下文里做、刚写完的代码用独立视角复核。这套纪律固定，值得打包成一个 skill——审查时一句话触发。
构建 code-review skill
帮我构建一个代码审查的 skill，命名 code-review，
保存到 ~/.claude/skills/code-review/。
流程要求：
1. 支持两种审查范围：当前未提交改动、当前分支与主分支的差异
2. 审查前先确认关注点：错误处理、API 兼容性、边界条件、命名一致性等
3. 每个发现必须贴出代码片段和具体场景：为什么有问题、什么输入会触发、哪个测试会失败
4. 重要审查先 /clear 或 /compact，在干净上下文里进行
5. 审查刚写完的代码时，派 verification 子代理独立复核生成的 SKILL.md 内容类似这样：
---
name: code-review
description: 审查代码时使用。用户要求 review 改动、检查 diff、评估未提交更改或分支差异时触发。
---
# 审查代码变更
1. **确认范围**：当前未提交改动（git diff），还是当前分支与主分支的差异
2. **确认关注点**：先问用户这次审查的重点（错误处理、API 兼容性、边界条件、命名一致性…）
3. **证据要求**：每个发现贴出代码片段和触发场景——什么输入会走到这条路径、
哪个测试会失败。不接受"看起来没问题"的结论
4. **干净上下文**：重要审查先 /clear 或 /compact，旧假说会污染判断
5. **独立复核**：审查刚写完的代码时，派 verification 子代理从独立上下文复核流程在做什么
- 先问关注点：审查没有重点等于没审查，先对齐目标再动手
- 证据要求：不带场景的审查结论无法验证。贴出代码片段，发现才能被讨论和确认
- 干净上下文：调试会话里积累的错误假说、试错片段会污染判断——新会话里 Peri 只依据代码本身
- 独立复核：写代码的人和审代码的人不该共享同一个上下文，确认偏误是审查的头号敌人
使用
用 code-review 审查当前未提交的改动，重点关注错误处理路径和边界条件Peri 会按流程走：确认范围 → 确认关注点 → 带证据审查。skill 的存放位置、自动加载机制和修改方式，见探索陌生代码库的说明。
进阶：审查一段范围（mattpocock code-review）
自定义的 code-review 审“当前变更”，mattpocock 的 code-review 审“自某个固定点以来的全部改动”（commit、分支、tag 或 merge-base），并行跑两个维度：Standards（是否符合项目编码标准）和 Spec（是否满足需求/PRD），输出并排报告。
获取方式：
npx skills add https://github.com/mattpocock/skills --skill code-review用法示例：
/code-review 审查 main 分支上自 origin/dev 以来的改动注意同名冲突：mattpocock 的 code-review 与自定义的 code-review 同名，同名时用户级优先——两个都想要的话，把自定义的换个名字（直接让 Peri 改 SKILL.md 里的 name 字段，如 review-changes），或只保留其中一个。