golang-how-to

The index to the rest of this Go collection: it reads what you are actually doing and pulls in every skill that applies, not just the most obvious one.

WHEN TO USE

SCOPE

USE FOR

Load every relevant skill at once for a task instead of just the first one that matches.
Resolve which of two overlapping skills, like performance vs benchmark, actually owns a question.
Configure a project's CLAUDE.md or AGENTS.md so this orchestrator always loads automatically.
Decide whether to reach for godig, gopls, Context7, or govulncheck for a specific package question.

This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.

In this document (6)

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 dependency exactly as pinned in go.sum, including replace directives pointing at forks or local paths — neither godig nor Context7 can see that. Its go_vulncheck operation runs a single, on-demand reachability check against the workspace as it stands right now.
govulncheck (the standalone CLI, wrapped by the samber/cc-skills-golang@golang-security skill) is the whole-tree audit: it walks the entire module's call graph to confirm which known vulnerabilities are actually reachable, and is the tool of record for CI gates and periodic security sweeps — gopls's go_vulncheck is a lighter-weight, single-shot version of the same analysis for use mid-edit.

Pick by task:

Task	Tool	How
Find where a symbol is defined in your own repo	`gopls`	`samber/cc-skills-golang@golang-gopls` — `go_search`, then `go_file_context`
Understand a file's intra-package dependencies	`gopls`	`samber/cc-skills-golang@golang-gopls` — `go_file_context`
Jump into a dependency's exact resolved source (incl. forks/`replace`d versions)	`gopls`	`samber/cc-skills-golang@golang-gopls` — `go_package_api`, or the native `LSP` tool's `goToDefinition`
Find every call site in your own code that references a dependency's symbol	`gopls`	`samber/cc-skills-golang@golang-gopls` — `go_symbol_references` — `godig`'s `imported-by` only lists public packages, not call sites in your repo
Get compiler diagnostics right after an edit	`gopls`	`samber/cc-skills-golang@golang-gopls` — `go_diagnostics` (MCP), or automatic with the native `LSP` tool
Check whether your current build can reach a known vulnerability, mid-edit	`gopls`	`samber/cc-skills-golang@golang-gopls` — `go_vulncheck`
Rename, extract, inline, or otherwise refactor local code	`gopls`	`samber/cc-skills-golang@golang-gopls` — safe rename, `refactor.*` code actions
Whole-tree vulnerability audit across the module (CI, periodic sweep)	`govulncheck`	`samber/cc-skills-golang@golang-security` skill — `govulncheck ./...`
List available versions of a published package	`godig`	`godig versions <path>`
Check known CVEs for a package/version you haven't added yet	`godig`	`godig vulns <path>`
See exported symbols/signatures of a published package	`godig`	`godig symbols` / `symbol doc`
Get runnable code examples for a symbol	`godig`	`godig symbol examples`
Read a package's rendered README/docs	`godig`	`godig module readme` / `package doc`
See who imports a package across the whole public ecosystem	`godig`	`godig imported-by`
Search for a package or library candidate	`godig`	`godig search`
Check a package's or module's license	`godig`	`godig package licenses` / `module licenses`
Get docs for a non-Go library, or a Go module not indexed on pkg.go.dev	Context7	`resolve-library-id` / `query-docs`

See the samber/cc-skills-golang@golang-pkg-go-dev skill for the full godig command reference, and the samber/cc-skills-golang@golang-security skill for the whole-tree govulncheck remediation workflow.

Categories at a glance

Full catalog with "use when" hooks: by-category.md

Category	Skills
Code Quality	`golang-code-style` `golang-documentation` `golang-error-handling` `golang-lint` `golang-naming` `golang-safety` `golang-security` `golang-structs-interfaces`
Architecture & Design	`golang-concurrency` `golang-context` `golang-data-structures` `golang-database` `golang-dependency-injection` `golang-design-patterns` `golang-modernize` `golang-refactoring`
QA & Performance	`golang-benchmark` `golang-observability` `golang-performance` `golang-testing` `golang-troubleshooting`
Project Setup	`golang-cli` `golang-continuous-integration` `golang-dependency-management` `golang-gopls` `golang-pkg-go-dev` `golang-popular-libraries` `golang-project-layout` `golang-stay-updated`
APIs	`golang-graphql` `golang-grpc` `golang-swagger`
Dependency Injection	`golang-dependency-injection` `golang-google-wire` `golang-uber-dig` `golang-uber-fx` `golang-samber-do`
Frameworks	`golang-spf13-cobra` `golang-spf13-viper`
samber/*	`golang-samber-do` `golang-samber-hot` `golang-samber-lo` `golang-samber-mo` `golang-samber-oops` `golang-samber-ro` `golang-samber-slog`
Testing	`golang-stretchr-testify` `golang-testing`

Competing clusters — boundary lines

Full boundary tables with routing examples: disambiguation.md

Key clusters and their owners:

Performance: golang-performance (optimization patterns) · golang-benchmark (measurement) · golang-troubleshooting (root cause) · golang-observability (always-on production)
DI: golang-dependency-injection (concepts/decision) · golang-google-wire (compile-time) · golang-uber-dig (runtime reflection) · golang-uber-fx (lifecycle framework) · golang-samber-do (type-safe container)
samber/*: golang-samber-lo (finite transforms) · golang-samber-ro (reactive streams) · golang-samber-mo (monadic types)
Errors: golang-error-handling (idioms) · golang-samber-oops (structured errors) · golang-safety (prevent panics)
Style: golang-code-style · golang-naming · golang-lint · golang-documentation
CLI: golang-cli (architecture) · golang-spf13-cobra (command tree) · golang-spf13-viper (config layering)
Package lookup: golang-pkg-go-dev (query pkg.go.dev for an existing path: versions/docs/symbols/importers/CVEs) · golang-gopls (navigate/refactor your locally resolved build) · golang-popular-libraries (which library to adopt) · golang-dependency-management (manage go.mod) · golang-security (whole-tree CVE scan)
Gap — type vs arch: golang-structs-interfaces (type design) vs golang-design-patterns (architectural patterns)
Gap — goroutine vs cancel: golang-concurrency + golang-context — load both when cancelling goroutines via context
Gap — correctness vs threat: golang-safety (internal bugs) vs golang-security (external threats)
Gap — features vs rules: golang-modernize (language adoption) vs golang-lint (static analysis config)
Gap — process vs target rules: golang-refactoring (the safe, staged, at-scale process of changing existing code — planning, ordering, gopls-driven mechanics, staged PRs) vs golang-naming/golang-code-style/golang-project-layout/golang-design-patterns/golang-modernize (what the resulting code should look like) — load golang-refactoring alongside whichever of these owns the target shape

Configure mode

Write an always-load directive for golang-how-to itself to the project's agent-config file (CLAUDE.md, AGENTS.md, GEMINI.md, Cursor rules, or Copilot instructions — whichever the project's harness reads), and optionally force-trigger specific secondary skills too.

samber/cc-skills-golang@golang-project-layout writes the always-load directive automatically at project creation, with no user confirmation needed — it costs one skill description and never imposes project-specific choices. Running /golang-how-to configure writes it too if missing, and additionally lets the user confirm a ## Required Go skills block for skills that must always apply beyond routing. Follow project-config.md.

This skill is not exhaustive. Refer to individual skill files and the official Go documentation for detailed guidance.

If you encounter a bug or unexpected behavior in this skill plugin, open an issue at https://github.com/samber/cc-skills-golang/issues.

Local tool required

1 FOR THE AGENT

01
Install gopls for code navigation
Install gopls with go install golang.org/x/tools/gopls@latest; for Claude Code's native LSP tool also set ENABLE_LSP_TOOL=1 and configure a Go language server.
```
go install golang.org/x/tools/gopls@latest
```

Listed as free: Connected services may require an account or charge fees.
Setup details: The README mentions source builds, cloning, containers, hosting, OAuth, service accounts, or cloud projects.

This skill ships inside the Samber Golang Skills plugin.

Install just this skill

Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.

Install checklist

Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.

Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.

npx skills add samber/cc-skills-golang --skill "golang-how-to" --full-depth

After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.

If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.

Install the whole plugin

This route installs the Samber Golang Skills plugin package selected for your AI tool.

Add Samuel's marketplace, then install the plugin

Type both lines inside a Claude Code session, not at your shell prompt. The marketplace is a separate repository of Samuel Berthe's, samber/cc, which also lists his other plugins. The second line opens the details of cc-skills-golang, which carries this repository's 46 Go skills; pick one of the install options shown and Claude Code installs it.

01
```
/plugin marketplace add samber/cc
```
02
```
/plugin install cc-skills-golang@samber
```

Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.openclaw/skills/cc-skills-golang, OpenClaw's skills folder in your home folder. To install it for one OpenClaw workspace instead, Samuel gives ~/.openclaw/workspace/skills/cc-skills-golang as the folder.

git clone https://github.com/samber/cc-skills-golang.git ~/.openclaw/skills/cc-skills-golang

Run it in your terminal, not inside Gemini CLI; installing from GitHub needs git on your computer. It installs the repository, with its 46 skills, as a Gemini CLI extension. To update it later, run gemini extensions update cc-skills-golang.

gemini extensions install https://github.com/samber/cc-skills-golang

Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.cursor/skills/cc-skills-golang, Cursor's skills folder in your home folder.

git clone https://github.com/samber/cc-skills-golang.git  ~/.cursor/skills/cc-skills-golang

Type it in an interactive GitHub Copilot CLI session, not at your shell prompt. It installs the repository straight from GitHub as a plugin, with its 46 skills and no marketplace to add first.

/plugin install https://github.com/samber/cc-skills-golang

Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.agents/skills/cc-skills-golang in your home folder.

git clone https://github.com/samber/cc-skills-golang.git ~/.agents/skills/cc-skills-golang

Open plugin page ↗

What's inside

Files included with this skill.

View on GitHub

Same repository

golang-benchmark
Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU/memory/trace profiles, analyzing results with benchstat, setting up CI benchmark regression detection, or investigating production performance with Prometheus runtime metrics. Also use when the developer needs deep analysis on a specific performance indicator - this skill provides the measurement methodology, while samber/cc-skills-golang@golang-performance provides the optimization patterns.Read full description
golang-cli
Golang CLI application development. Use when building, modifying, or reviewing a Go CLI tool — especially for command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion, argument validation, and CLI unit testing. Also triggers when code uses cobra, viper, or urfave/cli. For cobra-specific APIs → See samber/cc-skills-golang@golang-spf13-cobra skill; for viper configuration layering → See samber/cc-skills-golang@golang-spf13-viper skill.Read full description
golang-code-style
Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See samber/cc-skills-golang@golang-naming skill), linter configuration (→ See samber/cc-skills-golang@golang-lint skill), or doc comments (→ See samber/cc-skills-golang@golang-documentation skill).Read full description
golang-concurrency
Golang concurrency patterns. Use when writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Also triggers when you detect goroutine leaks, race conditions, channel ownership issues, or need to choose between channels and mutexes.Read full description
golang-context
Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values, context.WithoutCancel for background work outliving requests. Apply when designing context propagation across layers, debugging leaked or unexpired contexts, choosing between context.Background/TODO/WithoutCancel, or storing values in context. Not for code that merely accepts ctx as first parameter.Read full description
golang-continuous-integration
CI/CD pipeline configuration using GitHub Actions for Golang projects — testing, linting, SAST, security scanning, code coverage, Dependabot, Renovate, GoReleaser, code review automation, and release pipelines. Use when setting up or improving Go project CI, configuring GitHub Actions workflows, adding linters or security scanners, automating dependency updates, or adding quality gates.Read full description

Skill loading

Code navigation with gopls

godig vs gopls vs Context7 vs govulncheck

Categories at a glance

Competing clusters — boundary lines

Configure mode

Local tool required

Install just this skill

Install the whole plugin

Add Samuel's marketplace, then install the plugin

What's inside

More skills

golang-benchmark

golang-cli

golang-code-style

golang-concurrency

golang-context

golang-continuous-integration

`godig` vs gopls vs Context7 vs govulncheck