---

name: requesting-code-review description: "在完成任务、实现主要功能或合并前使用，以验证工作是否满足要求" risk: unknown source: community date_added: "2026-02-27"

请求代码审查

调度 superpowers: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 工具的 superpowers:code-reviewer 类型，填写 code-reviewer.md 中的模板

占位符：

• {WHAT_WAS_IMPLEMENTED} - 你刚构建了什么
• {PLAN_OR_REQUIREMENTS} - 它应该做什么
• {BASE_SHA} - 起始提交
• {HEAD_SHA} - 结束提交
• {DESCRIPTION} - 简要摘要

3. 根据反馈行动：

• 立即修复关键问题
• 在继续之前修复重要问题
• 记录次要问题留待以后处理
• 如果审查者错误则反驳（附带理由）

示例

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

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

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

[调度 superpowers:code-reviewer 子代理]
  WHAT_WAS_IMPLEMENTED: 会话索引的验证和修复函数
  PLAN_OR_REQUIREMENTS: docs/plans/deployment-plan.md 中的任务 2
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，支持 4 种问题类型

[子代理返回]:
  优点：干净的架构，真实的测试
  问题：
    重要：缺少进度指示器
    次要：魔法数字（100）用于报告间隔
  评估：可以继续

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

与工作流集成

子代理驱动开发：

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

执行计划：

• 每批（3 个任务）后审查
• 获取反馈，应用，继续

临时开发：

• 合并前审查
• 卡住时审查

红旗

永远不要：

• 因为"很简单"就跳过审查
• 忽略关键问题
• 带着未修复的重要问题继续
• 与有效的技术反馈争论

如果审查者错误：

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

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

何时使用

此技能适用于执行概述中描述的工作流或操作。

限制

• 仅在任务明确匹配上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需的输入、权限、安全边界或成功标准，请停下来寻求澄清。