requesting-code-review

请求代码审查

派遣代码审查子代理在问题级联之前捕获它们。审查者获得精心构建的评估上下文——绝不会包含你的会话历史。这使审查者专注于工作成果，而非你的思考过程，并保留你自己的上下文以继续工作。

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

何时请求审查

必须审查：

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

可选但有益：

• 遇到困难时（新视角）
• 重构前（基线检查）
• 修复复杂错误后

如何请求

1. 获取 Git SHA：

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

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

使用 Task 工具，类型为 general-purpose，填写 code-reviewer.md 模板

占位符：

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

3. 根据反馈行动：

• 立即修复严重问题
• 在继续前修复重要问题
• 记录次要问题以便后续处理
• 如果审查者错误，提出反驳（附上理由）

示例

[刚刚完成任务 2：添加验证函数]

你：让我在继续之前请求代码审查。

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

[派遣代码审查子代理]
  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，支持 4 种问题类型
  PLAN_OR_REQUIREMENTS: 来自 docs/superpowers/plans/deployment-plan.md 的任务 2
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[子代理返回]：
  优点：架构清晰，有真实测试
  问题：
    重要：缺少进度指示器
    次要：报告间隔使用了魔法数字 (100)
  评估：可以继续

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

与工作流集成

子代理驱动的开发：

• 每个任务后审查
• 在问题累积前捕获
• 修复后再进入下一个任务

执行计划：

• 每个任务后或在自然检查点审查
• 获取反馈，应用，继续

临时开发：

• 合并前审查
• 遇到困难时审查

危险信号

绝对不要：

• 因为“很简单”而跳过审查
• 忽略严重问题
• 在未修复重要问题的情况下继续
• 与有效的技术反馈争论

如果审查者错误：

• 用技术理由反驳
• 展示证明其工作的代码/测试
• 请求澄清

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