代码审查类 Skills

它替你干掉什么：十个能装的，先给表

装法（都是原样能敲的）

# 1) 本地：不用装，Claude Code 自带（/review 是它的别名）
/code-review                     # 审本分支领先 upstream 的提交 + 工作区改动
/code-review high                # 覆盖更广，代价是可能报不太确定的
/code-review --fix               # 审完直接把结论应用到工作区
/code-review main...my-feature   # 也能传 PR 号 / 分支 / 路径

# 2) CI：安全那条线（官方 Action，据仓库 README，2026-09）
- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

# 3) 装第三方审查 skill：两种都行
/plugin marketplace add aidankinzett/claude-git-pr-skill
/plugin marketplace add levnikolaevich/claude-code-skills
# 或者最土的办法：把 skill 文件夹整个拷进 ~/.claude/skills/

第一条立刻能跑的用法：在你手头这个还没提交的分支上敲 /code-review。它跑在一个自带上下文窗口的后台 subagent 里，不占你这一场的对话；结论回来了你再决定改哪几条。今天就能试，不用装任何东西。

机制：为什么「审查」是 skill 的甜区

条件一：高频，所以固定成本摊得薄

写一份审查清单要一小时，但它每个 PR 都跑一次。反过来，那种一年用两次的 skill，你写它的时间永远赚不回来——这就是为什么「审查」这一类能长出这么多能用的东西，而「年度总结」类长不出来。

条件二：有 oracle，所以意见能被证伪

oracle 就是「能判定对错的那个东西」：测试、类型检查、跑一遍真实行为。有 oracle 的意见是事实，没有的是口味。官方 webapp-testing（anthropics/skills）干的就是给前端改动补 oracle：用 Playwright 起服务（scripts/with_server.py）、等 networkidle、找选择器、截图、把 console 日志读回来。它自己说得很直白——先跑 --help，别一上来读源码。你也可以直接把这个文件夹拷进 ~/.claude/skills/。

为什么审查要跑在隔离的上下文里

三家的做法撞到了同一个答案。Claude Code 的 /code-review 默认作为后台 subagent 跑，自带上下文窗口；superpowers 的 requesting-code-review 取 BASE_SHA / HEAD_SHA 后另派一个 subagent、用仓库里的 code-reviewer.md 填参数，SKILL.md 明写理由是审查者绝不继承你这一场的会话历史；托管版 Code Review 则是多个 agent 按不同问题类别并行看，然后加一步验证——拿候选去对真实代码行为，过滤掉假阳性，再去重、按严重度排、贴到具体行上（据官方文档，2026-09）。

真实用法与边界：假阳性治理的三个旋钮

旋钮一：调 effort，换假阳性率

/code-review low / medium 只报最有把握的，high 到 max 覆盖更广、也会带上没那么确定的（据官方文档，2026-09）。默认它沿用你上次敲的等级，所以哪天觉得它变吵了，先想想是不是你上回顺手敲了 max。

旋钮二：用 REVIEW.md 把口径写死

托管版读仓库根目录的 REVIEW.md（CLAUDE.md 也读，但违规只按 nit 记）。四条最值钱的写法：重定义什么算 🔴 Important（默认口径是奔着生产代码去的，文档仓、原型仓该收窄）；给 nit 封顶（「最多报五条，其余在总结里给个数」）；skip 规则（生成代码、lockfile、CI 已经在管的 lint 和拼写）；抬验证门槛（「行为断言必须给出 file:line，不许从命名推断」）。还有一条治往返的：再审收敛——「第一轮之后只报 Important」，免得一行改动因为风格问题走到第七轮。

旋钮三：治你自己这一侧

最被低估的一个 skill 是 superpowers 的 receiving-code-review：它管的不是审查者，是收到意见的那个 agent。规矩是「先验证再实现，先问再假设」——实现之前先自查两件事：这条在本仓技术上成立吗？会不会弄坏现有功能？成立就改，不成立就用技术理由反驳、指向能跑的测试。它还明确禁止「你说得太对了！」这类表演式同意，要求直接说修法。这条规矩比任何审查器都重要：一个照单全收的下游，会把审查器的每一条假阳性都变成一次真实的代码劣化。

和 CI 门禁怎么分工

一条界线：有确定答案的交给 CI，需要判断的交给审查 agent。格式、lint、类型、依赖漏洞——这些 fail-closed 卡死，还不许审查 agent 再报一遍（写进 REVIEW.md 的 skip 规则）。而托管 Code Review 的 check run 永远以 neutral 收尾，不阻塞合并；真要卡，官方给的做法是自己从 check run 输出里解析那行机器可读的严重度计数（形如 {"normal":2,"nit":1,"pre_existing":0}），在你自己的 CI 里判。

代价与替代品：不装它你还能怎么办

三笔账

• 钱：Anthropic 托管的 Code Review 按 token 计费，官方给的口径是每次平均 15–25 美元，随 PR 大小和复杂度浮动，平均 20 分钟跑完（据官方文档，2026-09）。触发策略直接乘上去：「每次 push 都审」就是把这个数乘以你的 push 次数。它是 research preview，且只对 Team / Enterprise 开放。
• 噪声：见上一节。没配 REVIEW.md 的默认口径 + max 等级，是最容易把团队劝退的组合。
• 错觉：审查器不阻塞合并、也不承诺完备。它是多加的一层，不是替掉人审的那一层。

四条替代路线，从轻到重

1. 只用本地 /code-review：已经在你机器上了，零安装零账单。替你干掉「push 完才发现」；什么时候不够：只有你自己会跑，同事的 PR 它管不着。
2. CI 里挂开源的 The-PR-Agent/pr-agent（MIT；据 GitHub 仓库页 2026-09，约 12.9k star；原属 Qodo，现已捐给社区、迁到 PR-Agent org）：/review /describe /improve /ask 四条命令，GitHub Action 或 pip install pr-agent 本地跑，模型可换。什么时候不够：它看的是 PR 本身，不是你整个代码库。
3. 自己写 workflow：anthropics/claude-code-action（据 GitHub 仓库页 2026-09，约 8.8k star）：claude /install-github-app 一条命令装好，然后在 workflow 里给它一个 prompt。什么时候不够：你得自己维护提示词和触发条件——托管版省的正是这份活。
4. 安全单独拉一条线：/security-review（本地）+ claude-code-security-review（CI；据 GitHub 仓库页 2026-09，约 6.2k star）。它默认就把最容易误报的几类排除在外——DoS、限流、内存/CPU 耗尽、没有实证影响的通用输入校验、开放重定向。什么时候不够：它只管安全，别指望它讲代码风格。