requesting-code-review

请求代码审查

派遣 code-reviewer 子代理，及时发现问题，避免问题不断累积。

核心原则： 尽早审查，频繁审查。

何时请求审查

必须：

• 在子代理驱动开发中的每项任务完成后
• 完成主要功能后
• 合并到 main 之前

可选但很有价值：

• 遇到阻碍时（获取新的视角）
• 重构之前（检查基线）
• 修复复杂 bug 后

如何请求

1. 获取 git SHA：

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

2. 派遣 code-reviewer 子代理：

使用 Task 工具，选择 code-reviewer 类型，并填写 code-reviewer.md 中的模板

占位符：

• {WHAT_WAS_IMPLEMENTED} - 刚刚实现的内容
• {PLAN_OR_REQUIREMENTS} - 应实现的功能
• {BASE_SHA} - 起始提交
• {HEAD_SHA} - 结束提交
• {DESCRIPTION} - 简要摘要

3. 根据反馈采取行动：

• 立即修复 Critical 问题
• 继续之前修复 Important 问题
• 将 Minor 问题留待以后处理
• 如果审查者有误，请说明理由并提出异议

示例

[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]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

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

Task 工具模板

Task({
  task_id: 'task-1',
  subagent_type: 'general-purpose',
  model: 'sonnet',
  description: 'Code review for {DESCRIPTION}',
  prompt: `You are the CODE-REVIEWER agent.

## Instructions
1. Read your agent definition: .claude/agents/specialized/code-reviewer.md
2. Read memory: .claude/context/memory/learnings.md

## Review Request

### What Was Implemented
{WHAT_WAS_IMPLEMENTED}

### Requirements/Plan
{PLAN_OR_REQUIREMENTS}

### Git Range to Review
**Base:** {BASE_SHA}
**Head:** {HEAD_SHA}

Run these commands to see the changes:
\`\`\`bash
git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}
\`\`\`

## Memory Protocol
Record findings to .claude/context/memory/learnings.md when done.
`,
});

与工作流集成

子代理驱动开发：

• 每项任务完成后都进行审查
• 在问题累积之前发现它们
• 修复问题后再开始下一项任务

执行计划：

• 每批任务（3 项）完成后进行审查
• 获取反馈、应用反馈，然后继续

临时开发：

• 合并前进行审查
• 遇到阻碍时进行审查

危险信号

绝不：

• 因为“这很简单”而跳过审查
• 忽略 Critical 问题
• 在 Important 问题未修复时继续
• 与合理的技术反馈争辩

如果审查者有误：

• 给出技术理由并提出异议
• 展示能够证明代码可运行的代码或测试
• 请求澄清

参见模板：requesting-code-review/code-reviewer.md

铁律

1. 始终在派遣审查前记录 BASE_SHA 和 HEAD_SHA——如果没有准确的提交范围，审查者就无法准确分析差异。
2. 绝不因为某项改动“看起来很简单”而跳过代码审查——小改动与大改动会引入同类 bug；作者也无法发现自己的盲点。
3. 始终在继续下一项任务前修复 Critical 问题——未修复的关键问题会不断累积，随着更多代码叠加，越来越难以隔离。
4. 绝不与技术上正确的审查反馈争辩——只有在你有代码库证据表明审查者缺少背景信息或事实有误时，才提出异议。
5. 始终在每个必审节点请求审查（每项子代理任务之后、主要功能完成后、合并之前）——过晚请求审查，无法防止问题不断累积。

反模式

反模式	为什么会失败	正确做法
跳过对“小型”变更的审查	小型变更引发的 Bug 类型与大型变更相同；“简单”是主观且不可靠的判断	无论感知到的复杂程度如何，都在每个强制检查点请求审查
未提供 git SHA 就派发审查者	没有提交范围，审查者无法生成准确的差异；审查结果会不准确或不完整	每次派发审查前都记录 BASE_SHA 和 HEAD_SHA
遇到 Critical 问题仍继续	Critical 问题会不断累积；后续任务会建立在有缺陷的基础上，事后修复代价高昂	解决所有 Critical 问题后，再推进到下一个任务
将审查者的反馈视为可选项	可选审查会逐渐降低代码质量，并累积无法追溯的技术债	遵循严重级别升级规则：Critical → 立即修复，Important → 开始下一个任务前修复，Minor → 留待以后处理
一批任务完成后才请求审查，而不是每个任务完成后都请求	Task 1 中的错误会影响 Task 2–N；审查者无法区分哪些问题是由哪个任务引入的	每个任务完成后、开始下一个任务前进行审查

记忆协议（强制）

开始前： 阅读 .claude/context/memory/learnings.md

完成后：

• 新模式 -> .claude/context/memory/learnings.md
• 发现问题 -> .claude/context/memory/issues.md
• 做出决策 -> .claude/context/memory/decisions.md

假设会发生中断：如果没有记录在记忆中，就等于没有发生。