首页
/ Review Summary

Review Summary

2026-09-03 16:24:58作者:劳婵绚Shirley

Review Summary

Verdict: APPROVE | REQUEST CHANGES

Overview: [1-2 sentences summarizing the change and overall assessment]

Critical Issues

  • [File:line] [Description and recommended fix]

Important Issues

  • [File:line] [Description and recommended fix]

Suggestions

  • [File:line] [Description]

What's Done Well

  • [Positive observation — always include at least one]

Verification Story

  • Tests reviewed: [yes/no, observations]
  • Build verified: [yes/no]
  • Security checked: [yes/no, observations]

人格还附带六条硬性规则:先看测试(它们揭示意图与覆盖度)、评审前先读规格、每条 Critical/Important 必须带具体修复建议、有 Critical 问题不得批准、必须指出做得好的地方(至少一条)、不确定时明说并建议调查而不是猜。

## 评审流程五步与多模型评审

技能把评审过程固化为五步流程:

1. **理解上下文**——看代码前先弄清意图:这个变更想达成什么?实现了哪个规格/任务?预期行为变化是什么?
2. **先评审测试**——测试是否覆盖变更?测的是行为还是实现细节?边界是否覆盖?测试名是否有描述性?代码若回退,测试能否抓住?
3. **评审实现**——按五轴逐文件过一遍;
4. **分级发现**——给每条评论打上严重度标签(上表),避免作者把所有反馈都当成必改项;
5. **验证"验证本身"**——核查作者的验证故事:跑了哪些测试?构建是否通过?是否手动测过?UI 变更是否有截图?有无 before/after 对比?

技能还给出了**多模型评审模式**:

Model A writes the code │ ▼ Model B reviews for correctness and architecture │ ▼ Model A addresses the feedback │ ▼ Human makes the final call


不同模型有各自的盲区,交叉评审能抓住单模型漏掉的问题。配套示例提示词:

Review this code change for correctness, security, and adherence to our project conventions. The spec says [X]. The change should [Y]. Flag any issues as Critical, Required, Optional, or Nit.


此外技能还覆盖了三块常被忽略的评审内容:

- **死代码卫生**:任何重构后应识别、列出孤儿代码,并**先询问再删除**("Should I remove these now-unused elements: [list]?"),既不留垃圾也不静默删除;
- **评审速度**:一个工作日内响应是上限而非目标;单个变更通常应在一天内完成多轮评审;大型变更应要求作者拆分而不是硬评审;
- **依赖纪律**:加依赖前依次回答五问(现有栈能否解决?包体积多大?是否活跃维护?有无已知漏洞?许可证是否兼容?);升级依赖是"和其他变更一样的变更",风险最高的是 `bump deps` 式批量升级——应逐包读 changelog、一次变更只升一个依赖、以升级前后测试套件是否全绿为准、并审查 lockfile diff 而非只看 `package.json`。

## 评测体系:仓库如何验证 /review 的行为

仓库为这条命令链路配备了可执行的行为评测,位于 [evals/cases/code-review-and-quality.json](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/df1edb2e05487d0aa6d93c747141e0aed1187f25/evals/cases/code-review-and-quality.json?utm_source=gitcode_repo_files),可以从两个方向确认命令与技能是否被正确触发。

正向触发(应命中 `code-review-and-quality`):

- "Review this pull request before I merge it"
- "Do a quality pass on this diff for correctness and readability"
- "Can you review the changes another model just wrote for me?"

负向触发(应路由给其他技能,避免误触发):

- "Deploy this to production now" → 属于 `shipping-and-launch`
- "Write a failing test for the bug before fixing it" → 属于 `test-driven-development`

核心评测用例(id 1)给 Agent 一个真实的缺陷 diff 作为输入,并要求"提交一份结构化评审"。该 diff 保存在 [evals/fixtures/code-review-and-quality/user-search.diff](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/df1edb2e05487d0aa6d93c747141e0aed1187f25/evals/fixtures/code-review-and-quality/user-search.diff?utm_source=gitcode_repo_files)——一个新增的 `/users/search` 端点:

```diff
 router.get('/users/:id', requireAuth, getUser);
+router.get('/users/search', async (req, res) => {
+  const query = req.query.q;
+  const users = await db.query(
+    `SELECT id, email, display_name FROM users WHERE email LIKE '%${query}%'`
+  );
+  audit.log(`search by ${req.user.email}: ${query}`);
+  res.json({ users });
+});

这个 fixture 是被精心设计成"五轴靶子"的:用户输入直接拼进 SQL 模板字符串(安全轴——注入风险);query 未做任何校验(正确性轴);未做参数化、未限制返回数量(性能轴——无界数据拉取)。评测对输出提出四条预期:

  1. 发现覆盖多于一个评审轴;
  2. 每条发现带技能标签体系中的严重度;
  3. 对新端点的用户输入安全做了显式考虑;
  4. 评审以高杠杆发现开头,而不是先堆小瑕疵。

对照五轴清单,正确的评审应当至少标出一条 Critical:LIKE '%${query}%' 的字符串拼接是教科书式的 SQL 注入点。这个评测恰好演示了 /review 命令输出要求中"Critical 必须带 file:line 与修复建议"的标准形态。

命令、技能、人格三层的编排关系

docs/agents.md 把仓库的三层结构讲得很清楚:技能是 how(带步骤与出口标准的流程),人格是 who(采用单一视角、产出标准格式报告),命令是 when(面向用户的入口,负责组合人格与技能)。/review 属于"单人格背后的斜杠命令":它用项目的评审技能包装 code-reviewer 人格,给出单一视角的评审。

与它形成对照的是 /ship.claude/commands/ship.md)——一个 fan-out 编排器:并行派生 code-reviewersecurity-auditortest-engineer 三个人格,再在主上下文中合并出 go/no-go 决策。关键规则是人格之间互不调用(personas do not invoke personas),编排是斜杠命令的职责;Claude Code 平台上"subagent 不能再 spawn subagent"的约束天然强制了这一点。code-reviewer 人格文件的 Composition 一节也明确了自身定位:被 /review 单视角调用,或被 /ship 与另两个人格并行调用,但不应从其他人格内部被调用——需要安全审计时应在报告中以建议形式提出,而非自行委派。

使用方式

在 Claude Code 中安装该插件后,/review 即可直接在会话中使用;按 README 的说明,最快路径是通过 skills CLI:

npx skills add addyosmani/agent-skills --skill code-review-and-quality

或整体安装(安装全部 24 个技能,包含 .claude/commands/ 下的 8 个斜杠命令):

npx skills add addyosmani/agent-skills

Claude Code 的插件安装方式为:

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
1.12 K
2.72 K
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
903
1.82 K
docsdocs
暂无描述
Markdown
888
5.78 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件,TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件,使 PyTorch 框架能够直接调用昇腾 NPU,为开发者提供昇腾 AI 处理器的超强算力。
Python
854
1.34 K
kernelkernel
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
527
590
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
3.51 K
1.01 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.33 K
1.45 K
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR(Multi-Level Intermediate Representation)构建的,面向昇腾亲和算子编译时使用的中间表示,提供昇腾完备表达能力,通过编译优化提升昇腾AI处理器计算效率,支持通过生态框架使能昇腾AI处理器与深度调优
C++
540
384
flutter_flutterflutter_flutter
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.17 K
341