开发任务完成、重大功能实现或合并前，派发…

在完成任务、实现重大功能或合并到 main 前，派发 code-reviewer 子代理对照计划/需求审查实现，并按反馈修复问题。

适用场景

解决思路

1. 遵循“尽早审查、频繁审查”的核心原则，在开发过程中定期发起代码审查。
2. 在 subagent-driven development 中，每个任务完成后立即请求代码审查。
3. 完成重大功能后请求代码审查。
4. 合并到 main 前请求代码审查。
5. 可选但推荐：卡住时请求代码审查，以获取新视角。
6. 可选但推荐：重构前请求代码审查，作为基线检查。
7. 可选但推荐：修复复杂 bug 后请求代码审查。
8. 获取起始提交 SHA：运行 `BASE_SHA=$(git rev-parse HEAD~1)`，也可根据情况改用 `origin/main` 等作为基线。
9. 获取结束提交 SHA：运行 `HEAD_SHA=$(git rev-parse HEAD)`。
10. 使用 Task 工具，以 code-reviewer 类型派发代码审查子代理。
11. 填写 `code-reviewer.md` 模板来发起审查。
12. 在模板的 `{WHAT_WAS_IMPLEMENTED}` 占位符中填写刚实现的内容。
13. 在模板的 `{PLAN_OR_REQUIREMENTS}` 占位符中填写实现应满足的计划或需求。
14. 在模板的 `{BASE_SHA}` 占位符中填写起始提交。
15. 在模板的 `{HEAD_SHA}` 占位符中填写结束提交。
16. 在模板的 `{DESCRIPTION}` 占位符中填写简要总结。
17. 收到反馈后，立即修复 Critical 问题。
18. 收到反馈后，在继续之前修复 Important 问题。
19. 收到反馈后，记录 Minor 问题，留待后续处理。
20. 如果审查者判断错误，基于理由进行反驳/推回。
21. 在 Subagent-Driven Development 工作流中，每个任务后都审查，趁问题复合前捕获，并在进入下一任务前修复。
22. 在 Executing Plans 工作流中，每批（3 个任务）后审查，获取反馈、应用反馈后继续。
23. 在 Ad-Hoc Development 工作流中，合并前审查，卡住时审查。
24. 绝不因为“很简单”而跳过审查。
25. 绝不忽略 Critical 问题。
26. 绝不带着未修复的 Important 问题继续推进。
27. 绝不与有效的技术反馈争辩。
28. 如果审查者错误，用技术理由反驳。
29. 如果审查者错误，展示能证明代码可用的代码/测试。
30. 如果审查者错误，请求澄清。
31. 示例中可用 `BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')` 获取上一个任务提交作为起始 SHA；用 `HEAD_SHA=$(git rev-parse HEAD)` 获取结束 SHA。
32. 示例中派发子代理时填写：`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`。
33. 示例中审查返回 Strengths、Issues、Assessment 后，根据问题修复（例如修复 Missing progress indicators），然后继续下一个任务（如 Task 3）。
34. 查看模板位置：`skills/collaboration/requesting-code-review/code-reviewer.md`。

适用边界 · 注意事项

• 没有可调用的 Task 工具或 code-reviewer 子代理类型时，无法按本文派发子代理审查。
• 无法取得 git SHA 或没有可用的 BASE_SHA/HEAD_SHA 提交范围时，不能按本文的提交范围进行审查。
• 缺少计划或需求文档，无法填写 {PLAN_OR_REQUIREMENTS} 时，应先补齐需求，或改用不依赖计划对照的审查方式。