Skip to content
台灯与工作台

审查代码变更

代码审查的关键不在工具，在纪律：先对齐关注点、每个发现都要证据、重要审查在干净上下文里做、刚写完的代码用独立视角复核。这套纪律固定，值得打包成一个 skill——审查时一句话触发。

构建 code-review skill

Section titled “构建 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 子代理从独立上下文复核

流程在做什么

Section titled “流程在做什么”
  • 先问关注点：审查没有重点等于没审查，先对齐目标再动手
  • 证据要求：不带场景的审查结论无法验证。贴出代码片段，发现才能被讨论和确认
  • 干净上下文：调试会话里积累的错误假说、试错片段会污染判断——新会话里 Peri 只依据代码本身
  • 独立复核：写代码的人和审代码的人不该共享同一个上下文，确认偏误是审查的头号敌人

使用

Section titled “使用”
用 code-review 审查当前未提交的改动，重点关注错误处理路径和边界条件

Peri 会按流程走：确认范围 → 确认关注点 → 带证据审查。skill 的存放位置、自动加载机制和修改方式，见探索陌生代码库的说明。

进阶：审查一段范围（mattpocock code-review）

Section titled “进阶：审查一段范围（mattpocock code-review）”

自定义的 code-review 审”当前变更”，mattpocock 的 code-review 审”自某个固定点以来的全部改动”（commit、分支、tag 或 merge-base），并行跑两个维度：Standards（是否符合项目编码标准）和 Spec（是否满足需求/PRD），输出并排报告。

获取方式：

Terminal window
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），或只保留其中一个。

下一步

Section titled “下一步”