sp-requesting-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Requesting Code Review

请求代码评审

Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.

Core principle: Review early, review often.

调度代码评审子代理（subagent）在问题扩散前及时发现它们。评审者会获得专门为评估打造的精准上下文信息——绝不会获取你的会话历史。

核心原则： 尽早评审，经常评审。

When to Request Review

何时请求评审

Mandatory:

After each task in subagent-driven development
After completing major feature
Before merge to main

Optional but valuable:

When stuck (fresh perspective)
Before refactoring (baseline check)
After fixing complex bug

强制场景：

子代理驱动开发中完成每个任务后
完成重大功能开发后
合并至主分支（main）前

可选但推荐场景：

遇到瓶颈时（获取全新视角）
重构前（做基线检查）
修复复杂漏洞后

Model Selection

模型选择

Use the least powerful model that can handle the review, and always state it explicitly in the dispatch. An omitted model inherits your session's model — often the most capable and most expensive — so a two-file diff gets reviewed at architecture-tier cost, silently and with no error.

Scale it to the reading the review requires, not the diff's line count. The diff is the obvious input and the misleading one. What actually drives a review's cost is the scope you assign in the prompt: a single 200-line file checked for consistency against twenty others is a twenty-file review, while a thousand-line mechanical rename read on its own is a small one. Size the model to the reading — and notice that the reading is something you chose.

Small, mechanical diff, read on its own (one or two files, clear spec, no concurrency or security surface): a fast, cheap model.
Multi-file or judgment-heavy diff (cross-module coordination, subtle state, non-obvious failure modes): a standard model.
Whole-branch review before merge; anything touching concurrency, security or data integrity; or any review whose assignment sends the reviewer across many files it must hold at once: the most capable available model.

This is the same rule sp-subagent-driven-development applies to every seat it dispatches; that skill's Model Selection section is the fuller treatment, including fix-loop escalation and why turn count beats token price.

使用足以完成评审任务的最低规格模型，并且务必在调度时明确指定该模型。若未指定模型，将继承当前会话的模型——通常是功能最强、成本最高的型号，这会导致仅两行文件差异的评审却以架构级成本执行，且无任何提示。

根据评审所需的阅读量而非差异代码行数来选择模型。差异代码是直观的输入，但也容易误导人。真正决定评审成本的是你在提示词中定义的范围：单个200行文件需对照其他20个文件检查一致性，这属于20文件级别的评审；而千行规模的机械重命名只需单独阅读，属于小型评审。根据阅读量选择模型——请注意，阅读量是由你决定的。

小型机械差异，可独立阅读（1-2个文件，需求明确，无并发或安全风险）：使用快速、低成本的模型。
多文件或需主观判断的差异（跨模块协调、复杂状态、非显性故障模式）：使用标准模型。
合并前全分支评审；涉及并发、安全或数据完整性的任何内容；或需要评审者同时查阅大量文件的评审：使用当前可用的最强模型。

这一规则与sp-subagent-driven-development技能调度所有子代理时遵循的规则一致；该技能的模型选择章节有更详细的说明，包括修复循环升级以及为何交互轮次比令牌价格更重要。

How to Request

请求流程

1. Get git SHAs:

bash

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch code reviewer subagent:

Dispatch a

general-purpose

subagent, filling the template at code-reviewer.md

Placeholders:

```
{MODEL}
```
- REQUIRED. The reviewer's model, per Model Selection above.
```
{DESCRIPTION}
```
- Brief summary of what you built
```
{PLAN_OR_REQUIREMENTS}
```
- What it should do
```
{BASE_SHA}
```
- Starting commit
```
{HEAD_SHA}
```
- Ending commit

3. Act on feedback:

Fix Critical issues immediately
Fix Important issues before proceeding
Note Minor issues for later
Push back if reviewer is wrong (with reasoning)

1. 获取Git SHA值：

bash

BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. 调度代码评审子代理：

调度一个

general-purpose

子代理，填写code-reviewer.md中的模板

占位符说明：

```
{MODEL}
```
- 必填。根据上述模型选择规则指定评审使用的模型。
```
{DESCRIPTION}
```
- 对所开发内容的简要概述
```
{PLAN_OR_REQUIREMENTS}
```
- 功能应实现的需求
```
{BASE_SHA}
```
- 起始提交
```
{HEAD_SHA}
```
- 结束提交

3. 根据反馈行动：

立即修复严重（Critical）问题
推进工作前修复重要（Important）问题
记录次要（Minor）问题留待后续处理
若评审者判断错误，可提出反驳并给出理由

Example

示例

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[Dispatch code reviewer subagent]
  MODEL: a fast, cheap model - two functions, clear spec
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[Subagent returns]:
  Spec Compliance: ✅ Spec compliant
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

[刚完成任务2：添加验证功能]

你：在推进前我先请求代码评审。

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[调度代码评审子代理]
  MODEL: 快速低成本模型——仅两个函数，需求明确
  DESCRIPTION: 添加了verifyIndex()和repairIndex()，支持4种问题类型
  PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md中的任务2
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[子代理返回结果]:
  需求合规性：✅ 符合需求
  问题：
    重要：缺少进度指示器
    次要：报告间隔使用了魔法数字（100）
  评估：可推进后续工作

你：[修复进度指示器]
[继续执行任务3]

Common Rationalizations

常见误区

Excuse	Reality
"I'll just review the diff myself instead of dispatching a reviewer"	You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you.
"I'll leave the model off and let it pick"	There is no "it" that picks. An omitted model inherits your session's, which is usually the most expensive one you have - so the cheapest review you could have run costs the most. State the model on every dispatch.
"The reviewer needs my whole session history to understand the change"	Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process.

借口	实际情况
“我自己看差异代码就行，不用调度评审者”	你的角色是协调者——直接评审差异代码会占用你推进工作所需的上下文窗口。请调度评审子代理：差异代码和评估过程将在它的上下文中进行，只有评审结果会反馈给你。
“我不指定模型，让它自己选”	不存在“自动选择”的逻辑。若未指定模型，将继承当前会话的模型，通常是你拥有的最昂贵型号——本该成本最低的评审却花费了最高成本。每次调度都必须明确指定模型。
“评审者需要我的整个会话历史才能理解变更”	只提供专门打造的精准上下文，绝不要提供会话历史。这能让评审者聚焦于工作成果，而非你的思考过程。

Red Flags

注意事项

Never:

Skip review because "it's simple"
Ignore Critical issues
Proceed with unfixed Important issues
Argue with valid technical feedback

If reviewer wrong:

Push back with technical reasoning
Show code/tests that prove it works
Request clarification

See template at: code-reviewer.md

绝对禁止：

以“改动很简单”为由跳过评审
忽略严重（Critical）问题
带着未修复的重要（Important）问题推进工作
反驳合理的技术反馈

若评审者判断错误：

以技术理由提出反驳
展示能证明功能正常的代码/测试用例
请求对方澄清

模板地址：code-reviewer.md