reaperhero Go 开发
概述
当任务目标不是只做解释，而是要在 Go 项目里完成实际开发工作时，使用这个 skill。
默认目标是：
- 先理解现有包结构和代码风格
- 做最小且正确的改动
- 保持与仓库现有模式一致
- 在有清晰切入点时补充或更新测试
- 用最小但有效的命令完成验证
适用场景
当用户希望你：
- 实现或修改 Go 代码
- 修复 Go Bug
- 新增或更新 Go 测试
- 重构包、接口或模块边界
- 优化并发、上下文传递或错误处理
- 分析
go.mod、go.sum、构建标签或包结构 - 解释 Go 项目的调用链或架构设计
- 排查性能或内存问题
工作原则
- 改代码前先读本地代码，不要先入为主。
- 仓库已有风格优先于通用最佳实践。
- 除非任务明确要求，否则尽量保持现有 API 和包边界稳定。
- 优先写清晰、直白、可维护的代码，而不是炫技代码。
- 不引入没有必要的抽象。
- 能提炼成纯函数的逻辑，优先提炼后再测试。
- 修改应尽量小，避免把重构和行为变化混在一起。
- 尊重现有命名、文件组织和错误处理风格。
标准工作流
1. 建立上下文
优先检查：
go.mod- 目标包及其相邻文件
- 当前目录已有测试
- 相关接口、结构体和调用路径
在动手前先回答这几个问题：
- 这段行为归哪个包负责
- 最小可行改动是什么
- 仓库里有没有现成模式可以复用
- 是否已有 helper、抽象或公共逻辑可以沿用
2. 设计改动
优先：
- 最小 diff
- 稳定的导出 API
- 尽量不影响现有调用方
- 只在确实有助于测试时才提炼纯逻辑
避免：
- 没必要的大范围跨包改造
- 无必要引入第三方库
- 把“重构”和“改行为”混成一次提交
- 为了测试而过度设计 mock 结构
3. 实现代码
实现时应注意：
- 尽量让零值有意义
- 合适时把
context.Context放在第一个参数 - 返回错误时在必要处补充上下文
- 正常控制流不要依赖 panic
- goroutine 的生命周期、退出条件和取消路径要清晰
- 共享状态的同步方式要显式、易懂、可验证
4. 编写测试
优先遵循仓库风格。
默认测试规范：
- 优先使用 table-driven tests
- 使用
tests := []struct { ... } - 使用
t.Run(tt.name, func(t *testing.T) { ... }) - 断言风格尽量统一为
got/want - 错误信息统一为
xxx() = ..., want ... - 优先写纯单元测试，避免依赖外部服务、真实数据库、网络和环境状态
- 重点覆盖边界条件、空值、重复值、排序、去重、保持原值等核心行为
如果目标目录已经有测试：
- 模仿现有命名方式
- 模仿现有断言风格
- 模仿现有 helper 和 fixture 组织方式
- “按仓库风格写测试”优先于“只要测试能过”
5. 验证结果
优先运行最小验证命令：
go test ./path/to/package- 必要时再运行
go test ./... - 如果只是构建问题，可先做定向 build
- 如果只是某个函数或某个包改动，不要一上来全量跑
如果因为环境、依赖或时间原因无法验证，要明确说明。
Go 代码风格要求
包设计
- 一个包只负责一类清晰职责。
- 避免循环依赖，抽象应放在真正拥有该行为的边界上。
- 导出面尽量小。
- 在真正需要抽象给调用方之前，优先使用具体类型而不是接口。
错误处理
- 错误应返回，不要静默吞掉。
- 传播错误时在必要场景补上下文。
- 除非仓库已有一致模式，否则不要同时 log 再 return 同一个错误。
- 只有在调用方确实需要判断时才使用 sentinel error。
- 只有在行为依赖结构化错误信息时才引入自定义错误类型。
并发
- 每个 goroutine 都应有明确生命周期。
- 优先使用
context做取消控制。 - channel 用于协调，不要把它当成所有共享状态问题的通用替代。
- 当互斥锁是最简单正确的方案时，直接用 mutex。
- 避免在超时、提前返回或消费方退出时泄漏 goroutine。
测试
- 测试应尽量小、稳定、确定。
- 除非仓库本来就是这么测，否则避免依赖真实网络、数据库、文件系统和环境变量。
- 能提炼纯逻辑时，优先提炼后测试，而不是堆复杂 mock。
- 只有任务与性能有关时才补 benchmark。
输出要求
完成任务后，输出应包含：
- 改了什么
- 关键假设是什么
- 做了哪些验证
- 如果测试没覆盖到，剩余风险在哪里
Prompt 示例
Use $go-development 修复当前包里的这个 bug，并补充聚焦测试。Use $go-development 按仓库风格重构这段 Go 逻辑，但不要改变行为。Use $go-development 为这个目录补 table-driven tests。Use $go-development 分析这段调用链，并解释包结构设计。
Resources
- 当需要更细的测试规范时，读取 references/testing.md