requesting-code-review

用途

本技能用于在完成任务、实现重大功能或合并代码前请求代码审查，通过派发代码审查子代理，在问题级联扩散之前将其捕获。审查者获得的是精确构造的上下文，而非你的会话历史，这使审查者专注于工作产物而非你的思考过程，同时保留你自己的上下文以继续工作。

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

何时请求审查

强制时机：

子代理驱动开发中每个任务完成后
完成重大功能后
合并到主分支前
变更涉及安全相关代码时——不可信输入、认证/授权、密钥、注入汇聚点、子进程/插件边界或新依赖（派发 security-reviewer）

可选但有价值：

卡住时（获取新视角）
重构前（基线检查）
修复复杂 bug 后

如何请求

获取 git SHA：

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

使用 task 工具派发 code-reviewer、code-quality-reviewer 或 security-reviewer 全局代理：

code-reviewer、code-quality-reviewer 和 security-reviewer 代理已在全局注册，并带有相应的审查清单。调用时提供关于已实现内容、计划引用和 git diff 范围的上下文。代理将使用 git diff {BASE_SHA}..{HEAD_SHA} 检查变更。

Task 工具提示中应包含的上下文：

你刚构建了什么（简要总结）
它应该做什么（计划或需求引用）
起始提交 SHA（BASE_SHA）
结束提交 SHA（HEAD_SHA）

根据反馈行动：

立即修复 Critical 问题
继续前修复 Important 问题
记录 Minor 问题以备后续
如果审查者有误，用理由反驳

示例

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

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

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

[使用 `task` 工具派发 code-reviewer 子代理]
  WHAT_WAS_IMPLEMENTED: 会话索引的验证与修复函数
  PLAN_OR_REQUIREMENTS: docs/plans/deployment-plan.md 中的 Task 2
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，含 4 种问题类型

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

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

与工作流集成

子代理驱动开发：

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

执行计划：

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

临时开发：

合并前审查
卡住时审查

选择审查者

代理	使用时机	拒绝事项
spec-reviewer	实现后立即——代码是否符合规范，不多不少？	评论风格或质量
code-quality-reviewer	规范符合性通过后——分解、命名、错误处理、测试质量	重新争论范围
security-reviewer	变更涉及不可信输入、认证/授权、密钥、注入汇聚点、子进程/插件边界或新依赖时——在规范和质量通过后	报告没有追踪输入到影响路径的发现
code-reviewer	功能结束或合并前——整个变更的生产就绪性	—
reviewing-interface-quality（技能）	变更包含面向用户的 UI	—

顺序很重要。先运行规范符合性，再代码质量，再安全，最后生产就绪审查。在规范符合性之前运行质量审查会浪费精力打磨可能并非所需代码；在规范符合性之前运行安全审查会审计可能故意错误的行为。参见 subagent-driven-development。

编写派发提示

审查者开始时没有上下文。你写的内容就是他们知道的全部——绝不是你的会话历史。给审查者模糊的提示会得到模糊的发现。

提示按此顺序包含：

构建了什么——两句话
它应该做什么——需求或计划任务文本，完整粘贴，而非文件引用
diff 范围——BASE_SHA 和 HEAD_SHA
在哪里查看——变更的文件
你已知的内容——你做的偏差及原因
你想要什么返回——报告格式

粘贴需求文本。告诉审查者去读 docs/plans/x.md 会消耗一次工具调用，并有读错任务的风险。你已经有文本了。

不要告诉他们你的想法。“我认为错误处理很扎实”会使审查偏向同意。陈述事实，请求发现。

审查 auth 计划中 Task 2 的实现。

需求（逐字来自计划）：
  向 src/index/verify.ts 添加 verifyIndex() 和 repairIndex()。verifyIndex()
  返回跨 4 种类型的问题列表：orphaned、stale、duplicate、
  missing。repairIndex() 修复每种类型。每 100 项报告进度。

DIFF: git diff a7981ec..3df7661
FILES: src/index/verify.ts, src/index/types.ts, tests/index/verify.test.ts

已知偏差：使用了 WeakMap 而非计划指定的 Map，
因此条目随其请求对象一起被回收。行为相同。

返回：PASS 或 FAIL，每个发现附 file:line 引用。

根据反馈行动

必需子技能：在实现任何建议前使用 receiving-code-review。审查者有时会出错，盲目实现错误建议比不审查更糟。

严重性	行动
Critical	在做任何其他事之前修复
Important	在下一任务前修复
Minor	记录；便宜就修，否则推迟

然后重新审查。发现问题的审查者并未批准修复。用相同上下文加上变更内容重新派发。跳过重新审查是“已修复”问题存活到合并的方式。

危险信号

绝不：

因为“很简单”而跳过审查
忽略 Critical 问题
带着未修复的 Important 问题继续
与有效的技术反馈争论
让审查者读计划文件而非粘贴任务文本
在提示中包含你自己的评估（使审查有偏差）
未经重新审查就接受修复为完成
审查未提交的工作——先提交，使 diff 范围真实

如果审查者有误：

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

常见错误

用会话上下文派发。审查者继承你的假设，审查你的推理而非代码。
没有 diff 范围。审查者读取整个文件，评论不属于本次变更的既有代码。
提交前审查。没有稳定范围可 diff，审查者可能看到半保存状态。
一个审查者同时负责规范和质量。它们是不同问题，合并意味着范围问题得到的关注少于所需。
将审查视为形式。如果每次审查都返回“已批准，无问题”，要么提示有偏差，要么用错了审查者。