指导开发者以技术严谨性处理代码审查反馈，强调验证而非盲从、行动胜过言辞的工作方法论，避免表演式认同，确保代码质量优先。
说明：
## 核心用法
`receiving-code-review` 是一个**行为准则型 Skill**，用于规范 AI 助手接收代码审查反馈时的响应模式。它不提供自动化工具，而是通过结构化决策流程指导开发者：
1. **阅读 → 理解 → 验证 → 评估 → 回应 → 实施** 的六步响应模式
2. 强制禁止表演式语言（”You’re absolutely right!” / “Great point!” / “Thanks!”）
3. 对每项建议进行技术验证：是否适配当前代码库、是否破坏现有功能、是否符合 YAGNI 原则
4. 区分反馈来源：人类合伙人（可信但需确认范围）vs 外部审查者（需 skepticism）
5. 处理不明确反馈时的强制停止机制——必须先澄清全部项目再实施
### 显著优点
– **根治行业通病**：针对开发者常见的”收到反馈就改”的盲从行为，建立技术验证防火墙
– **YAGNI 检查机制**：通过 `grep codebase` 验证功能真实使用情况，防止过度工程化
– **冲突升级路径**：明确区分技术分歧与架构决策冲突，后者必须上升给人类合伙人
– **心理安全设计**：提供 “Strange things are afoot at the Circle K” 暗号，允许在不直接说”不”的情况下表达不适
– **可逆性保障**：要求逐项实施、逐项测试，避免批量修改导致的回归问题
### 潜在缺点与局限性
– **摩擦成本**：严格的验证流程在紧急迭代中可能拖慢节奏，需团队共识支撑
– **暗语依赖**：”Circle K” 暗号的文化特异性（美国电影《比尔和泰德的奇异冒险》典故）可能造成理解障碍
– **外部关系风险**：持续的 skepticism 可能损害与外部贡献者的协作关系，需配合礼貌的技术表达
– **无自动化**：纯文档型 Skill，依赖开发者自律执行，无强制校验机制
– **上下文局限**：未覆盖异步审查（如 GitHub PR 已合并后的评论）的特殊处理
### 适合人群
– 技术团队负责人，希望统一代码审查响应规范
– 频繁与外部开源贡献者交互的维护者
– 在快速迭代中常因”改错方向”浪费工时的开发者
– 使用 Claude Code 等 AI 编程助手、希望减少 AI 讨好行为的团队
### 常规风险
– **执行衰减**：文档型 Skill 的 compliance 完全依赖用户记忆，长期可能流于形式
– **过度推回**：新手可能误用”技术推回”机制，将合理建议当作错误拒绝
– **协作张力**：外部审查者可能因缺少正向反馈感到被冷落，需额外沟通成本
会员专属
