code-review

该技能是一套代码审查实践指南，核心是技术正确性优先于社交舒适：先验证再实施，先提问再假设，先有证据再下结论，并遵循 YAGNI、KISS、DRY 原则。它包含三类实践。一是接收反馈：收到任何来源的评审意见时，按读取、理解、验证、评估、回应、实施的顺序处理；不做事先的表演式附和；不清楚之处先停下来澄清；对外部评审者的建议要先做技术验证并检查是否破坏现有功能，若与既有决策冲突可基于技术理由反驳；对建议的"正规"功能先用 grep 确认使用情况再决定是否实施。二是请求审查：在子代理驱动开发中每个任务完成后、重大功能或重构完成时、合并主分支前、遇到瓶颈或修复复杂缺陷后触发；流程为先取 git SHA，即 BASE_SHA=$(git rev-parse HEAD~1) 和 HEAD_SHA=$(git rev-parse HEAD)，再通过 Task 工具派发 code-reviewer 子代理，附上实现内容、计划或需求、BASE_SHA、HEAD_SHA 与描述，最后按反馈处理：严重问题立即修复，重要问题在继续前修复，次要问题记录待办。三是验证门：铁律是未取得新的验证证据不得声称完成；步骤为确定命令、完整运行、读取输出、确认与声明一致后再声明，跳过任一步即等于说谎而非验证。要求包括测试输出显示零失败、构建命令退出码为 0、原始症状测试通过、需求逐条核对。红旗信号是使用"应该""大概""看起来"等措辞、未验证就表达满意、未验证就提交、轻信代理报告。三类实践各在参考文件中给出完整协议，触发条件分别对应接收评审意见、完成任务、准备声明成功或完成之时。具体参考文件的完整内容与更多细节暂未提供。