name: code-review-communication description: 用于有效给予和接收代码审查反馈的框架。适用于PR评论、审查策略、处理分歧以及平衡细致与友善。 allowed-tools: Read, Glob, Grep

代码审查沟通

本技能提供有效的代码审查沟通框架 - 包括给予反馈得当和接收反馈不设防。

何时使用此技能

撰写代码审查评论，希望其清晰且具有建设性
接收感觉苛刻的反馈，需要视角转换
希望区分阻塞性问题和次要建议
需要沟通代码质量关切而不损害关系
准备审查初级开发者的第一个PR

核心框架

常规评论

一种标签系统，使每个评论的意图一目了然。

格式： [标签] (修饰): 解释

标签：

标签	含义	所需操作
`praise`	突出好的工作	无 - 鼓励
`nitpick`	次要风格/偏好问题	可选
`suggestion`	改进想法	考虑但不必须
`issue`	必须解决	合并前必须解决
`question`	需要澄清	需要响应
`thought`	分享观点	无 - 仅供参考

修饰：

(non-blocking) - 明确可选
(blocking) - 必须解决
(if-minor) - 仅当修复简单时

示例：

praise: 这个错误处理非常彻底 - 我喜欢你覆盖了边缘情况。

nitpick (non-blocking): 考虑使用比 `x` 更具描述性的变量名。

suggestion: 你可以在这里使用 `Object.entries()` 以获得更清晰的迭代。

issue (blocking): 这个SQL查询容易受到注入攻击。使用参数化查询。

question: 如果用户在操作中途取消，预期行为是什么？

thought: 我过去看到过这种模式在并发请求中引起问题。

完整参考： references/conventional-comments.md

总结-分析-建议方法

对于较大的审查或需要多个评论时：

总结 - 以什么工作良好开始（真诚的积极方面）
分析 - 识别需要关注的具体领域
建议 - 以可操作的推荐结束

这防止了使作者防御的“批评墙”效应。

分离代码与编码者

最重要的原则：批评代码，而不是人。

而不是…	说…
“你写错了这个”	“这个函数可以简化”
“你没有考虑X”	“这里有一个关于X的边缘情况”
“你为什么这样做？”	“这种方法的理由是什么？”
“你应该知道更好”	“这是一个常见的陷阱 - 这里是模式”

使用协作的“我们”语言：

“我们应该为此添加一个测试”
“我们应该如何处理空值情况？”
“让我们考虑性能影响”

阻塞性与非阻塞性

阻塞性问题（必须修复）：

安全漏洞
将导致生产问题的错误
对公共API的破坏性更改
关键路径缺失必需测试

非阻塞性问题（有则更好）：

风格偏好
替代实现
次要优化
文档改进

经验法则： 如果作者忽略此评论你也能接受，那就是非阻塞性的。

接收反馈

良好接收代码审查反馈同样重要。参见 references/receiving-feedback.md 了解：

假设善意
分离自我与代码
询问澄清问题
专业处理分歧
何时离线讨论

版本历史

v1.0.0 (2025-12-26): 初始发布

最后更新

日期： 2025-12-26 模型： claude-opus-4-5-20251101

代码审查沟通技能Skill code-review-communication