| name | loom-receiving-code-review |
| description | Process code review feedback: classify items, implement fixes, push back with reasoning when needed. Triggered after receiving review comments on a PR or branch. Use when: code review comments have arrived and need triage, fixes, or reasoned disagreement.
|
| when_to_use | Triage review feedback, implement valid fixes, and respond with evidence when pushing back. |
| argument-hint | <review comments or PR context> |
| user-invocable | true |
接受代码审查
触发条件
- 收到代码审查反馈后触发
loom-requesting-code-review 发出请求后，收到反馈时自动触发
完成条件与下一步
- 所有 BLOCKER 和必须修复项已处理
- 审查者确认通过
- 下一步：使用
loom-finishing-a-development-branch 收尾分支
核心原则
技术严谨 > 社交舒适。 验证后再行动，不搞表演性同意。
审查反馈是需要技术评估的输入，不是情感表演的机会。
禁止的回复
永远不要：
- "你说得对！"（表演性同意）
- "好主意！"（无意义附和）
- "我马上改！"（未验证就行动）
应该：
- 重述技术要求
- 提出澄清问题
- 用技术推理 push back
- 直接行动（行动 > 语言）
正确的反馈回复：
✅ "已修复。[简述改动]"
✅ "好发现 - [具体问题]。已修复于 [位置]。"
✅ [直接修复，通过代码展示]
❌ "你说得对！"
❌ "好主意！"
反馈来源区分
- human partner：理解后直接实施，范围不清时确认，不附和
- 外部审查者：实施前必须验证技术正确性、兼容性和上下文完整性
详细检查清单见 references/response-templates.md
YAGNI 与 Push Back
- 审查者建议"properly implement"时，先 grep 确认是否真的在用；未使用则建议删除
- 建议破坏现有功能、缺乏上下文、违反 YAGNI、与架构决策冲突时，用技术推理 push back
- 不清楚的反馈：停止实施，先确认所有不清楚的项
完整 YAGNI 检查流程、push back 方式和不清楚反馈示例见 references/response-templates.md
执行流程
Step 1：理解审查反馈
- 逐一阅读审查意见
- 分类反馈：
- 必须修复：BLOCKER
- 建议修复：SUGGESTION
- 讨论：需要进一步讨论
Step 2：分类处理
BLOCKER（必须修复）：
- 理解问题
- 实施修复
- 验证修复
SUGGESTION（建议修复）：
- 评估建议的合理性
- 决定采纳或拒绝
- 如果拒绝，提供理由
讨论项：
- 与审查者沟通
- 达成共识
- 按共识处理
Step 3：实施修复
- 按审查意见修改代码
- 运行测试确保修复正确
- 提交修复
Step 4：回复审查
使用 references/response-templates.md 中的统一模板格式回复审查意见。
Step 5：再次提交
git add <modified-files>
git commit -m "fix: 根据审查反馈修复 xxx"
git push
约束
- BLOCKER 必须全部修复
- SUGGESTION 必须明确回复采纳或拒绝
- 拒绝建议时必须提供理由
- 修复后必须重新运行测试
