/golang-how-to
Golang skills orchestrator — always active on any Golang coding, review, debug, or setup task. Reads the task context and loads the most relevant skills from samber/cc-skills-golang, often multiple at once: writing a gRPC service loads golang-grpc + golang-testing +
$ npx -y skills add samber/cc-skills-golang --skill golang-how-to --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/golang-how-to
Context preview
The summary Claude sees to decide when to auto-load this skill.
Golang skills orchestrator — always active on any Golang coding, review, debug, or setup task. Reads the task context and loads the most relevant skills from samber/cc-skills-golang, often multiple at once: writing a gRPC service loads golang-grpc + golang-testing +
SKILL.md
golang-how-to.SKILL.mdname: golang-how-to
description: "Golang skills orchestrator — always active on any Golang coding, review, debug, or setup task. Reads the task context and loads the most relevant skills from samber/cc-skills-golang, often multiple at once: writing a gRPC service loads golang-grpc + golang-testing + golang-error-handling; debugging a panic loads golang-troubleshooting + golang-safety; auditing security loads golang-security + golang-lint + golang-safety. Also: disambiguates competing clusters when two skills seem to overlap (performance vs benchmark vs troubleshooting, samber/lo vs mo vs ro, DI cluster, safety vs security), and configures CLAUDE.md or AGENTS.md to force-trigger skills in a project (/golang-how-to configure)."
user-invocable: true
license: MIT
compatibility: Designed for Claude Code or similar AI coding agents. Requires git.
metadata:
author: samber
version: "1.3.0"
openclaw:
emoji: "🧭"
homepage: https://github.com/samber/cc-skills-golang
requires:
bins:
- go
- gopls
install:
- kind: go
package: golang.org/x/tools/gopls@latest
bins: [gopls]
allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(git:*) Agent AskUserQuestion LSP Bash(gopls:*) mcp__gopls__***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.
**Dependencies:** `gopls` — `go install golang.org/x/tools/gopls@latest`; the built-in `LSP` tool also needs `ENABLE_LSP_TOOL=1` and a Go language server wired (see [Code navigation with gopls](#code-navigation-with-gopls)).
**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](references/disambiguation.md).
- **Configure** — write the always-load directive for `golang-how-to` itself, plus an optional `## Required Go skills` block, to the project's `CLAUDE.md` or `AGENTS.md`. Follow [project-config.md](references/project-config.md).
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 dependenc
Read more
name: golang-how-to
description: "Golang skills orchestrator — always active on any Golang coding, review, debug, or setup task. Reads the task context and loads the most relevant skills from samber/cc-skills-golang, often multiple at once: writing a gRPC service loads golang-grpc + golang-testing + golang-error-handling; debugging a panic loads golang-troubleshooting + golang-safety; auditing security loads golang-security + golang-lint + golang-safety. Also: disambiguates competing clusters when two skills seem to overlap (performance vs benchmark vs troubleshooting, samber/lo vs mo vs ro, DI cluster, safety vs security), and configures CLAUDE.md or AGENTS.md to force-trigger skills in a project (/golang-how-to configure)."
user-invocable: true
license: MIT
compatibility: Designed for Claude Code or similar AI coding agents. Requires git.
metadata:
author: samber
version: "1.3.0"
openclaw:
emoji: "🧭"
homepage: https://github.com/samber/cc-skills-golang
requires:
bins:
- go
- gopls
install:
- kind: go
package: golang.org/x/tools/gopls@latest
bins: [gopls]
allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(git:*) Agent AskUserQuestion LSP Bash(gopls:*) mcp__gopls__***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.
**Dependencies:** `gopls` — `go install golang.org/x/tools/gopls@latest`; the built-in `LSP` tool also needs `ENABLE_LSP_TOOL=1` and a Go language server wired (see [Code navigation with gopls](#code-navigation-with-gopls)).
**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](references/disambiguation.md).
- **Configure** — write the always-load directive for `golang-how-to` itself, plus an optional `## Required Go skills` block, to the project's `CLAUDE.md` or `AGENTS.md`. Follow [project-config.md](references/project-config.md).
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 dependenc
AI agent skills are reusable instruction sets that extend your coding assistant with domain-specific expertise, loaded on demand so they don't bloat your context. This repository covers Go-specific skills only (language, testing, security, observability, etc.)
Other skills on cc-skills-golang.
- /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
Open skill - /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
Open skill - /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
Open skill - /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,
Open skill - /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
Open skill - /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
Open skill

