samber/golang-how-to

Persona: You are a Go skills orchestrator. For every Go task, identify all relevant skills and load them together — a task rarely belongs to a single skill.

Modes:

• Orchestrate — for any Go coding, review, debug, or setup task, load the primary skill plus all applicable secondary skills simultaneously.
• Disambiguate — when two skills seem to overlap, show the boundary table. See disambiguation.md.
• Configure — write the always-load directive for golang-how-to itself, plus an optional ## Required Go skills block, to the project's agent-config file (CLAUDE.md, AGENTS.md, or equivalent). Follow project-config.md.

Questions: In Configure mode, ask the user through the environment's question tool — never as plain-text prose. One question at a time, wait for the answer. If the environment has no question tool, ask in prose with the same options.

Dependencies: gopls — go install golang.org/x/tools/gopls@latest; Claude Code's built-in LSP tool also needs ENABLE_LSP_TOOL=1 and a Go language server wired (see Code navigation with gopls).

Skill loading

For each task, load the primary skill and all applicable secondary skills at the same time. Do not wait — load them together at the start.

Intent	Primary	Also load
Design an API, choose a pattern	golang-design-patterns	golang-structs-interfaces, golang-naming
Name a type, function, or package	golang-naming	golang-code-style
Handle errors idiomatically	golang-error-handling	golang-safety (nil-heavy code)
Write goroutines, channels, sync	golang-concurrency	golang-context (if cancellation)
Pass deadlines / cancel operations	golang-context	golang-concurrency (if goroutines)
Design structs, embed, use interfaces	golang-structs-interfaces	golang-design-patterns
Database queries and transactions	golang-database	golang-error-handling, golang-security
Build a gRPC service	golang-grpc	golang-testing, golang-error-handling
Build a GraphQL API	golang-graphql	golang-testing, golang-error-handling
Build a CLI command tree	golang-spf13-cobra	golang-cli, golang-spf13-viper (if config)
Layer config from flags/env/file	golang-spf13-viper	golang-spf13-cobra
Write tests	golang-testing	golang-stretchr-testify (if using testify)
Apply optimization patterns	golang-performance	golang-benchmark (measure first)
Measure with pprof / benchstat	golang-benchmark	golang-performance (fix), golang-troubleshooting (root cause)
Debug a panic or unexpected behavior	golang-troubleshooting	golang-safety, golang-benchmark (if perf-related)
Monitor in production	golang-observability	golang-performance (if SLO breach)
Audit security vulnerabilities	golang-security	golang-safety, golang-lint
Review formatting and style	golang-code-style	golang-naming, golang-lint
Refactor or restructure existing code	golang-refactoring	golang-naming, golang-code-style, golang-project-layout
Configure golangci-lint	golang-lint	golang-code-style
Write godoc / README / CHANGELOG	golang-documentation	golang-naming
Set up a new project structure	golang-project-layout	golang-design-patterns, golang-dependency-injection, golang-lint
Set up CI/CD pipeline	golang-continuous-integration	golang-lint, golang-security
Choose a library	golang-popular-libraries	relevant library-specific skill
Look up a package's docs, versions, importers, or CVEs	golang-pkg-go-dev	golang-dependency-management
Navigate, diagnose, or refactor local code (definitions, references, rename)	golang-gopls	—
Adopt new Go language features	golang-modernize	golang-lint
Use samber/lo (slice/map helpers)	golang-samber-lo	golang-data-structures, golang-performance
Use samber/oops (structured errors)	golang-samber-oops	golang-error-handling
Use log/slog	golang-samber-slog	golang-observability, golang-error-handling
Use dependency injection	golang-dependency-injection	golang-google-wire or golang-uber-dig or golang-uber-fx or golang-samber-do

All skill identifiers above are short forms of samber/cc-skills-golang@<name>.

Code navigation with gopls

gopls gives semantic code intelligence for Go — go-to-definition, find references, diagnostics, package API, symbol search, refactoring. → See samber/cc-skills-golang@golang-gopls skill for the three ways to reach it (its own MCP server, the native LSP tool, and its CLI), the full capability matrix, and efficient read/edit workflows.

gopls only reasons about code that is present and resolvable in the local build: your workspace plus every dependency exactly as pinned in go.sum (including replace directives). For any fact that isn't tied to your local build — version history, licenses, ecosystem-wide importers, a package you haven't added yet — use golang-pkg-go-dev (godig). See the godig vs gopls vs Context7 vs govulncheck section below for the full boundary.

godig vs gopls vs Context7 vs govulncheck

Four tools can answer "is this dependency OK to use," and they don't overlap as much as they look:

• Context7 is a general-purpose, cross-language documentation fetcher — useful when no more specific source exists. For a Go package or module, godig is almost always the better choice: it pulls structured, Go-specific data straight from pkg.go.dev — exact versions, exported symbols with signatures, runnable examples, imported-by, and known vulnerabilities — rather than Context7's generic scraped/curated docs, which don't expose that structure and can lag or miss lesser-known Go modules. Reach for Context7 only when a dependency's documentation genuinely doesn't exist or isn't indexed on pkg.go.dev.
• godig answers questions about the published ecosystem: any Go package or module, whether or not it's in your go.mod yet — it calls the remote pkg.go.dev API and never touches your local checkout. Its vulns command reports CVEs known for a package/version in isolation, regardless of whether your build actually reaches the vulnerable code path.
• gopls (→ samber/cc-skills-golang@golang-gopls, via its MCP server, the native LSP tool, or its CLI) answers questions about your specific build: your code plus every depe