用途：覆盖代码评审的两个方向——发起评审与接收反馈，适用于完成主要功能后、合并到主分支前、子代理工作流的每个任务后、遇到卡点时、重构前以及修复复杂缺陷后。
发起评审时需提供：已实现内容（给评审者的上下文）、需求或计划引用、基线 SHA（起点）、头 SHA（终点）以及简要摘要（便于快速定位）。
处理反馈按严重程度分级：Critical 立即修复；Important 在继续前修复；Minor 记录待后续处理；有异议则带理由推回。
接收评审的核心原则是先验证再实现、先询问再假设，技术正确性优先于社交舒适。响应流程为：完整读完反馈不急于反应、复述需求或询问、对照代码库实际验证、评估是否适合当前代码库、给出技术性确认或有理由的推回、逐项实现并逐项测试。若反馈有不清楚之处，应先停止并全部澄清后再动手，因为部分理解容易导致错误实现。
推回的适用情形包括：建议破坏现有功能、评审者缺乏完整上下文、属于 YAGNI 未使用功能、对当前技术栈不正确、存在遗留或兼容性原因、与架构决策冲突。推回时使用技术推理、提出具体问题、引用可运行的测试或代码、展示证据，避免防御性、情绪化争论与简单说“不”。
多项修复的顺序：先澄清不清楚项；再按阻塞问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）依次实现；每项单独测试并确认无回归。
回应应使用技术性表达，如“已修复，附简要描述”“继续前需澄清 X”“基于技术理由建议维持现方案”“缺少 X 无法验证，是否调查”，避免“你说得完全对”“好点子”等表演式回应，也不要在验证前直接声称开始实现。
按来源处理：来自用户的反馈在理解后可直接实施；外部评审者需先做技术评估再实施；自动化工具需先核验是否适用于当前上下文。
限制：资料未提供具体命令、安装方式、收费信息或支持平台，暂未提供。