| name | requesting-code-review |
| description | 在完成任务、实现重要功能或合并前使用,用于验证当前工作是否满足要求 |
| metadata | {"acadclaw":{"profiles":["reviewer"],"produces":["review_report"],"consumes":["experiment_code"]}} |
请求代码评审
调用 superpowers:code-reviewer 子代理,在问题扩散前尽早发现风险。
核心原则: 早评审,常评审。
何时请求评审
必须请求的场景:
- 在子代理驱动开发中,每完成一个任务后
- 完成一个重要功能后
- 合并到主分支前
可选但很有价值的场景:
- 卡住时,需要一个新视角
- 重构前,先做一次基线检查
- 修复复杂 bug 后
如何请求评审
1. 获取 git SHAs:
BASE_SHA=$(git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)
2. 调用 code-reviewer 子代理:
使用 Task 工具并选择 superpowers:code-reviewer 类型,套用下方内嵌模板。
占位符说明:
{WHAT_WAS_IMPLEMENTED} - 你刚完成的内容
{PLAN_OR_REQUIREMENTS} - 它本来应该实现什么
{BASE_SHA} - 起始提交
{HEAD_SHA} - 结束提交
{DESCRIPTION} - 简要说明
3. 根据反馈行动:
- 立即修复 Critical 问题
- 继续推进前先修复 Important 问题
- Minor 问题可记录后续处理
- 如果评审判断有误,应给出技术性反驳理由
示例
[Just completed Task 2: Add verification function]
You: 我先请求一次代码评审,再继续推进。
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch superpowers:code-reviewer subagent]
WHAT_WAS_IMPLEMENTED: 为会话索引新增校验与修复函数
PLAN_OR_REQUIREMENTS: docs/plans/deployment-plan.md 中的 Task 2
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: 新增 verifyIndex() 和 repairIndex(),覆盖 4 类问题
[Subagent returns]:
Strengths: 架构清晰,测试有效
Issues:
Important: 缺少进度提示
Minor: 上报间隔中的魔数 100
Assessment: 可以继续
You: [补上进度提示]
[继续处理 Task 3]
与工作流的集成
子代理驱动开发:
- 每完成一个任务就评审一次
- 在问题累积前提前发现
- 修完再进入下一任务
执行计划时:
- 每完成一批任务(如 3 个)后评审
- 接收反馈,修正后继续
临时开发场景:
风险信号
绝不要:
- 因为“很简单”就跳过评审
- 忽略 Critical 问题
- 带着未修复的重要问题继续推进
- 对有效的技术反馈强行争辩
如果评审结论不对:
- 用技术理由反驳
- 展示代码或测试来证明
- 必要时请求澄清
内嵌评审模板
调用 code-reviewer 子代理时,直接使用下面这份模板。
# 代码评审代理
你正在评审一组代码变更,目标是判断它是否具备生产可用性。
**你的任务:**
1. 评审 {WHAT_WAS_IMPLEMENTED}
2. 对照 {PLAN_OR_REQUIREMENTS} 检查实现是否符合要求
3. 检查代码质量、架构和测试
4. 按严重程度归类问题
5. 评估是否已达到生产可用标准
## 已实现内容
{DESCRIPTION}
## 需求/计划
{PLAN_REFERENCE}
## 需要评审的 Git 区间
**Base:** {BASE_SHA}
**Head:** {HEAD_SHA}
```bash
git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}
评审检查清单
代码质量:
- 职责分离是否清晰?
- 错误处理是否充分?
- 是否具备类型安全性(如适用)?
- 是否遵循 DRY 原则?
- 边界情况是否覆盖?
架构:
- 设计决策是否合理?
- 是否考虑可扩展性?
- 是否存在性能影响?
- 是否有安全隐患?
测试:
- 测试是否真正覆盖逻辑,而不只是 mock?
- 边界情况是否覆盖?
- 是否在需要时加入集成测试?
- 测试是否全部通过?
需求符合性:
- 是否满足计划中的全部要求?
- 实现是否符合规格?
- 是否出现范围蔓延?
- 破坏性变更是否已记录?
生产可用性:
- 如果涉及 schema 变化,是否有迁移策略?
- 是否考虑向后兼容?
- 文档是否完整?
- 是否不存在明显 bug?
输出格式
优点
[做得好的地方是什么?请具体说明。]
问题
Critical(必须修复)
[Bug、安全问题、数据丢失风险、功能损坏]
Important(应该修复)
[架构问题、功能缺失、错误处理不足、测试缺口]
Minor(可选优化)
[代码风格、性能优化机会、文档改进]
对每个问题,都应说明:
- 文件与行号
- 问题是什么
- 为什么重要
- 如何修复(如果不是显而易见)
建议
[Improvements for code quality, architecture, or process]
结论评估
是否可以合并? [Yes/No/With fixes]
理由: [用 1 到 2 句话给出技术判断]