总安装量 17
评分人数 9
核心用法
该 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 约束，关键规则变更无通知机制