receiving-code-review

核心用法

该 Skill 是一套处理代码审查反馈的行为规范指南，核心目标是消除"表演式同意"，建立技术优先的审查响应流程。使用时遵循"READ-UNDERSTAND-VERIFY-EVALUATE-RESPOND-IMPLEMENT"六步模式：先完整阅读反馈、用自己的话重述需求、对照代码库验证、评估技术合理性、给出技术回应或合理反驳、最后逐项实施并测试。

显著优点

1. 反表演设计：明确禁止"You're absolutely right!"等社交辞令，强制用技术事实替代情绪劳动
2. 防御性思维：针对外部审查者设置五重验证清单（技术正确性、功能破坏性、原实现理由、跨平台兼容性、上下文完整性）
3. YAGNI 检查机制：提供具体命令（grep 代码库）验证"专业级功能"是否真有调用，避免过度工程
4. 分级处理策略：区分"人类伙伴"（高信任，可跳过验证）与"外部审查者"（需 skepticism）的不同响应方式
5. 纠错礼仪：即使反驳错误也能体面承认，用"You were right - I checked [X]"替代冗长道歉

潜在缺点与局限性

1. 文化冲突风险：在强调"心理安全"的团队中，直接反驳可能引发人际摩擦
2. 上下文依赖："人类伙伴"的信任关系需要预先建立，新团队难以直接套用
3. 无自动化能力：纯文档指南，不提供与 GitHub/GitLab API 的集成，无法自动拉取 PR 评论
4. 特定技术栈假设：示例中的 grep、gh CLI 等命令暗示 Unix-like 环境，Windows 开发者需适配
5. 暗号机制隐患："Strange things are afoot at the Circle K"作为求助信号，若团队未统一认知会失效

适合的目标群体

• 技术驱动型团队的资深开发者，尤其是担任代码审查主导角色的人员
• 开源项目维护者，需要处理大量外部 PR 反馈
• 远程协作团队，文字沟通占比高、需减少误解的场景
• 经历过"盲目实施错误建议导致生产事故"的技术负责人

使用风险

1. 流程摩擦成本：严格执行六步模式可能延长简单修复的响应时间
2. 团队规范冲突：若组织已有强制的"感谢文化"，该 Skill 的"禁止感谢"规则可能引发合规问题
3. 过度自信陷阱："VERIFY"步骤依赖使用者自身的技术判断力，经验不足者可能误判正确建议
4. 无版本控制：作为个人项目（T3 来源），内容更新不受企业 SLA 约束，关键规则变更无通知机制

核心功能

receiving-code-review 是一项面向 Claude Code Agent 的提示词技能，旨在规范代码审查反馈的处理流程。其核心目标是建立技术严谨性优先的工作原则，避免盲从和表演式回应。

显著优点

1. 技术导向明确：强制要求验证（Verify）→ 评估（Evaluate）→ 实施（Implement）的三段式流程，杜绝"收到即执行"的草率行为
2. 禁止表演性语言：明确列出禁用语如 "You're absolutely right!"、"Great point!" 等，推动以技术陈述替代社交客套
3. 分层处理机制：

4. YAGNI 原则落地：要求 grep 代码库确认实际使用场景，避免过度工程化
5. 清晰推回指南：提供技术理由推回的具体场景和话术，降低工程师心理负担

• 对人类合作伙伴（trusted）：实施前仍需确认范围
• 对外部审查者：执行 5 项技术检查（正确性、破坏性、上下文、兼容性、冲突性）

潜在局限

• 语境依赖强：需要 Agent 具备代码库 grep、测试执行等实际能力，纯提示词无法独立完成验证
• 文化适配成本：在强调礼貌和层级感的团队中，"无感谢用语"原则可能需要额外解释
• 外部审查摩擦：推回策略若使用不当，可能引发协作冲突，需配合 "Strange things are afoot at the Circle K" 等隐晦信号机制

适合人群

• 使用 Claude Code Agent 进行日常开发的工程师
• 需要处理大量代码审查反馈的技术团队
• 追求高效技术沟通、减少社交噪音的远程协作团队

常规风险

该技能本身为纯 Markdown 文档，无代码执行风险。主要风险在于应用层面：Agent 可能因提示词权重问题过度推回合理建议，或在团队未达成共识时显得"机械冷漠"。建议结合团队代码规范文档同步使用。