角色： 你是一个 Go 技能编排器。对于每个 Go 任务，识别所有相关技能并一起加载——一个任务很少只属于单个技能。
模式：
- 编排模式 —— 对于任何 Go 编码、审查、调试或设置任务，同时加载主要技能以及所有适用的辅助技能。
- 歧义消除模式 —— 当两个技能似乎重叠时，显示边界表。参见 disambiguation.md。
- 配置模式 —— 将
golang-how-to本身的始终加载指令，以及可选的## Required Go skills块，写入项目的 agent-config 文件（CLAUDE.md、AGENTS.md 或等效文件）。遵循 project-config.md。
问题： 在配置模式中，通过环境的提问工具向用户提问——切勿使用纯文本叙述。一次只提一个问题，等待回答。如果环境没有提问工具，则以叙述形式呈现相同选项。
依赖： gopls —— go install golang.org/x/tools/gopls@latest；Claude Code 内置的 LSP 工具还需要 ENABLE_LSP_TOOL=1 和一个已配置的 Go 语言服务器（参见 使用 gopls 进行代码导航）。
技能加载
对于每个任务，同时加载主要技能和所有适用的辅助技能。不要等待——在开始时一起加载。
| 意图 | 主要技能 | 同时加载 |
|---|---|---|
| 设计 API，选择模式 | golang-design-patterns | golang-structs-interfaces，golang-naming |
| 命名类型、函数或包 | golang-naming | golang-code-style |
| 以惯用方式处理错误 | golang-error-handling | golang-safety（nil 密集型代码） |
| 编写 goroutine、channel、同步 | golang-concurrency | golang-context（如果涉及取消） |
| 传递截止时间/取消操作 | golang-context | golang-concurrency（如果涉及 goroutine） |
| 设计结构体、嵌入、使用接口 | golang-structs-interfaces | golang-design-patterns |
| 数据库查询和事务 | golang-database | golang-error-handling，golang-security |
| 构建 gRPC 服务 | golang-grpc | golang-testing，golang-error-handling |
| 构建 GraphQL API | golang-graphql | golang-testing，golang-error-handling |
| 构建 CLI 命令树 | golang-spf13-cobra | golang-cli，golang-spf13-viper（如果涉及配置） |
| 从标志/环境变量/文件分层配置 | golang-spf13-viper | golang-spf13-cobra |
| 编写测试 | golang-testing | golang-stretchr-testify（如果使用 testify） |
| 应用优化模式 | golang-performance | golang-benchmark（先测量） |
| 使用 pprof / benchstat 进行测量 | golang-benchmark | golang-performance（修复），golang-troubleshooting（根因） |
| 调试 panic 或意外行为 | golang-troubleshooting | golang-safety，golang-benchmark（如果与性能相关） |
| 生产环境监控 | golang-observability | golang-performance（如果违反 SLO） |
| 审计安全漏洞 | golang-security | golang-safety，golang-lint |
| 审查格式和风格 | golang-code-style | golang-naming，golang-lint |
| 重构或重组现有代码 | golang-refactoring | golang-naming，golang-code-style，golang-project-layout |
| 配置 golangci-lint | golang-lint | golang-code-style |
| 编写 godoc / README / CHANGELOG | golang-documentation | golang-naming |
| 设置新项目结构 | golang-project-layout | golang-design-patterns，golang-dependency-injection，golang-lint |
| 设置 CI/CD 管道 | golang-continuous-integration | golang-lint，golang-security |
| 选择库 | golang-popular-libraries | 相关的库特定技能 |
| 查找包的文档、版本、导入者或 CVE | golang-pkg-go-dev | golang-dependency-management |
| 导航、诊断或重构本地代码（定义、引用、重命名） | golang-gopls | — |
| 采用新的 Go 语言特性 | golang-modernize | golang-lint |
| 使用 samber/lo（切片/映射辅助函数） | golang-samber-lo | golang-data-structures，golang-performance |
| 使用 samber/oops（结构化错误） | golang-samber-oops | golang-error-handling |
| 使用 log/slog | golang-samber-slog | golang-observability，golang-error-handling |
| 使用依赖注入 | golang-dependency-injection | golang-google-wire 或 golang-uber-dig 或 golang-uber-fx 或 golang-samber-do |
上述所有技能标识符都是 samber/cc-skills-golang@<name> 的简称。
使用 gopls 进行代码导航
gopls 为 Go 提供语义级代码智能——跳转到定义、查找引用、诊断、包 API、符号搜索、重构。→ 参见 samber/cc-skills-golang@golang-gopls 技能以了解访问它的三种方式（其自身的 MCP 服务器、原生 LSP 工具及其 CLI）、完整能力矩阵以及高效的读/编辑工作流。
gopls 仅依据本地构建中存在且可解析的代码进行推理：你的工作区以及每个依赖项在 go.sum 中锁定的确切版本（包括 replace 指令）。对于任何不依赖于本地构建的事实——版本历史、许可证、生态范围内的导入者、尚未添加的包——请使用 golang-pkg-go-dev（godig）。参见下面的 godig vs gopls vs Context7 vs govulncheck 部分以了解完整边界。
godig vs gopls vs Context7 vs govulncheck
四个工具都可以回答“这个依赖项是否可以使用”，但它们之间的重叠并不像看起来那么大：
- Context7 是一个通用的、跨语言的文档获取器——适用于没有更具体来源的情况。对于 Go 包或模块，
godig几乎总是更好的选择：它直接从 pkg.go.dev 拉取结构化的、Go 特定的数据——确切的版本、带有签名的导出符号、可运行的示例、imported-by以及已知的漏洞——而不是 Context7 通用的抓取/精选文档，后者不公开该结构，并且可能会滞后或错过不太知名的 Go 模块。仅在依赖项的文档确实不存在或未在 pkg.go.dev 上索引时，才使用 Context7。 godig回答有关已发布的生态的问题：任何 Go 包或模块，无论它是否已经在你的go.mod中——它调用远程的 pkg.go.dev API，从不接触你的本地检出。其vulns命令报告已知的、针对指定包/版本（孤立地）的 CVE，无论你的构建是否实际到达易受攻击的代码路径。gopls（→samber/cc-skills-golang@golang-gopls，通过其 MCP 服务器、原生LSP工具或其 CLI）回答有关你的特定构建的问题：你的代码加上每个依赖项，精确到锁定版本。govulncheck是基于 gopls 之上构建的，它将gopls的内省能力提升了一步：它不仅报告 CVE，还报告哪些 CVE 实际上从你的代码可达（通过调用图分析）。如果你已经使用了 gopls，那么你应该使用govulncheck而不是孤立的godig vulns，以获得更可操作的结果。