Quality Review Feedback

接收评审意见时，重点不是“态度好”，而是技术判断准确。这个 skill 约束的是收到反馈后的处理动作。

何时使用

• 你刚收到 code review 反馈
• 反馈里有几项你并不完全理解
• 反馈来自外部 reviewer，需要先判断是否适合当前代码库
• 用户明确触发 /review-feedback

不适用：

• 你还没有收到任何反馈
• 你只是在发起评审，而不是处理评审结果

产物

每次使用本 skill，默认产出以下最小集合：

1. 反馈处理记录
   • 哪些项已理解
   • 哪些项需澄清
   • 哪些项准备采纳或反驳
2. 实施结论
   • 已修项
   • 待确认项
   • 明确拒绝项及理由
3. 质量记录
   • 若当前任务已有自己的记录文件，回写 Review Feedback 阶段摘要
   • 若没有既定记录位置，默认写入 .quality/quality-check.md

工作流

1. 读取
   • 先把反馈完整看完，不抢着表态
2. 理解
   • 用自己的话复述每一项技术要求
3. 核实
   • 对照代码库、测试和上下文确认是否成立
4. 评估
   • 判断这条建议对当前代码库是否正确、是否会破坏现有行为
5. 回应
   • 正确就修
   • 不清楚就先澄清
   • 不成立就给技术性反驳
6. 实现
   • 一次处理一项，逐项验证

纪律约束

• 不要表演性认同
• 不要盲从外部 reviewer
• 不清楚时先澄清，不要边猜边改
• 外部建议如果会破坏现有行为、脱离上下文或违反 YAGNI，可以反驳
• 可以回写到当前任务记录，但不能假设调用方一定有某种固定目录结构
• 没有任务容器时，也应把处理结果落在 .quality/quality-check.md，而不是只写在回复里

常见禁区

• “你说得对，我马上改”
• “好建议，我全收下”
• 还没核实就开始大改
• 有两项没看懂，却先实现另外四项

这里追求的是技术正确，不是礼貌表演。