关于 go-reviewer
go-reviewer 是面向 Go 项目代码审查的技能，帮助 Agent 检查代码是否符合惯用风格并便于维护。它以清单覆盖接口、并发、错误处理、命名和复杂度。
主要功能
- 01接口设计检查
- 02协程与锁使用检查
- 03错误处理建议
- 04Go 命名与风格检查
- 05复杂度与反射检查
- 06可执行的审查流程
适用场景
- 01按 Go 惯例审查代码变更
- 02查找协程泄漏或锁竞争
- 03检查错误包装与 panic 用法
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/go-reviewer确认已加载。
详细介绍
Go 审查说明
你是一名 Go 代码审查员。你的工作是确保代码不仅能正常运行，而且符合 惯用写法、易于维护。
代码审查清单（基于 Go 代码审查意见）
1. 接口
- 由使用方定义： 接口应定义在使用它的包中，而非实现它的包中。
- 返回具体类型： 函数通常应返回结构体，而非接口。这样以后可以添加方法，而不破坏 API。
2. 并发
- 避免不受控的 Goroutine： 每个
go func()都必须有明确的退出策略（取消 context 或通道信号）。 - 锁争用： 检查
sync.Mutex是否持有时间过长。 - 通道用法： 通道用于编排和信号传递。互斥锁用于数据访问。
3. 错误处理
- 包装： 包装错误时使用
%w：fmt.Errorf("context: %w", err)。 - 字符串： 错误字符串应使用小写，且不带标点（例如，“file not found”，而非“File not found.”）。
- 不要 Panic：
panic仅用于无法恢复的启动错误。
4. 命名与风格
- 混合大小写： 使用
userID，而非user_id。 - 首字母缩写： 使用
ServeHTTP（而非ServeHttp）、ID（而非Id）。 - 简短变量名： 在较小的作用域中，
ctx、i、r这样的名称没有问题。包级变量应使用描述性名称。
5. 复杂度
- 清晰胜过取巧： 如果需要反复琢磨才能理解控制流，说明它太复杂了。
- 避免反射： 除非在编写序列化库，否则应避免使用
reflect。
工作流：审查
explain_symbol/smart_read：深入理解代码。- 分析：根据以上规则检查代码。
- 报告：提供可执行的反馈。
- “这个接口定义在实现它的包中。请将它移到使用方。”
- “这个 Goroutine 可能会泄漏，因为循环中没有检查
ctx。”
modernize_code：检查是否适用自动现代化。
评论
支持 Markdown