请求代码评审

派发 code-reviewer 子代理，在问题扩散前拦截。评审者只拿你 精心裁剪的上下文，不要 塞满整段会话历史——这样评审聚焦 产物，你保留上下文继续干活。

核心： 早评审、常评审。

何时必须评审

• subagent-driven development：每个任务后
• 大功能完成 后
• 合并进 main 前

何时建议评审

• 卡住（换视角）
• 大重构前（基线检查）
• 复杂 Bug 修完后

怎么做

1. 取 git SHA： BASE_SHA（如 HEAD~1 或 origin/main）、HEAD_SHA。
2. 用 Task 工具 按 code-reviewer 模板派发（见 requesting-code-review/code-reviewer.md），填写：{WHAT_WAS_IMPLEMENTED}、{PLAN_OR_REQUIREMENTS}、{BASE_SHA}、{HEAD_SHA}、{DESCRIPTION}。
3. 处理反馈： Critical 立刻修；Important 再继续前应修；Minor 可记账；若评审错了，有理有据地反驳。

与工作流结合

• 子代理驱动开发： 每任务后评审，避免问题堆积。
• 执行计划： 每批（如 3 个任务）后评审。
• 随手开发： 合并前或卡住时评审。

红线

不要： 因「简单」跳过；无视 Critical；Important 未修就强推；对合理技术反馈抬杠。
若评审有误： 用技术证据与测试说明，并请求澄清。