请求代码审查

派发一个代码审查子代理，以便在问题级联之前捕获它们。审查者获得精心构建的上下文用于评估——绝不能是你会话的历史记录。

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

何时请求审查

强制：

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

可选但有价值：

• 当卡住时（新鲜视角）
• 在重构之前（基线检查）
• 在修复复杂 bug 之后

如何请求

1. 获取 git SHAs：

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

2. 派发代码审查子代理：

派发一个 general-purpose 子代理，填写位于 [code-reviewer.md](code-reviewer.md) 的模板

占位符：

• {DESCRIPTION} - 你构建内容的简要摘要
• {PLAN_OR_REQUIREMENTS} - 它应该做什么
• {BASE_SHA} - 起始 commit
• {HEAD_SHA} - 结束 commit

3. 根据反馈行动：

• 立即修复严重问题
• 在继续之前修复重要问题
• 记录次要问题以便稍后处理
• 如果审查者错了，请反驳（附带理由）

示例

[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]
  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]:
  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]

常见合理化借口

| 借口 | 现实 | |--------|---------| | "我自己审查 diff 就行，不必派发审查者" | 你是协调者——内联审查 diff 会消耗你需要持续驱动工作的上下文窗口。派发一个审查者子代理：diff 和评估保存在它的上下文中，只有发现会返回给你。 | | "审查者需要我的整个会话历史才能理解这个变更" | 交给它精心构建的上下文，绝不能是你的会话历史。这能让审查者专注于工作产物，而不是你的思考过程。 |

危险信号

绝不：

• 因为“它很简单”而跳过审查
• 忽略严重问题
• 带着未修复的重要问题继续
• 与有效的技术反馈争辩

如果审查者错了：

• 用技术推理反驳
• 展示能证明它可用的代码/测试
• 请求澄清

参见模板：[code-reviewer.md](code-reviewer.md)