A Go handbook that agents can load on demand
cc-skills-golang turns coding guidance into Agent Skills: directories with metadata, instructions, references, assets, and sometimes commands that a compatible assistant can discover and load for a task. Instead of pasting one huge Go prompt into every session, users install the collection and let the client trigger a focused skill for testing, concurrency, database work, performance, or another topic.
The repository is unusually broad. General skills cover naming, error handling, data structures, contexts, dependency injection, security, observability, project layout, continuous integration, modules, gopls, documentation, and modernization. More specific skills address gRPC, GraphQL, Swagger, Cobra, Viper, Wire, Dig, Fx, Testify, and the author's own Go libraries. This is closer to a modular engineering handbook than a handful of prompt snippets.
The author says the material began with Claude Code and Go project commits, then received human editing, testing, review, and rework. That provenance is more credible than an automatically generated prompt dump, but each rule still deserves ordinary technical review.
The modular design is both strength and cost
Atomic skills keep irrelevant material out of a normal request. A benchmark task can load measurement guidance without loading every database pattern. Descriptions in frontmatter remain visible so the agent can decide when a skill applies, while detailed references arrive only after selection. The README publishes token counts for descriptions, core files, and full directories, which helps users see the context cost instead of pretending it is free.
The modules also cross-reference shared conventions. Error behavior may live in the error-handling skill while its logging consequence lives in observability. The README warns that installing only a subset can create a partial or inconsistent view and recommends installing the general-purpose group together. That creates a tension: completeness asks for more skills, while reliable triggering and finite context favor shorter descriptions and fewer candidates.
An open July 2026 issue makes the tension concrete. The reporter says the descriptions become large enough that Codex shortens them to fit a skills context budget. A shorter trigger description can hide useful distinctions and make selection less precise. Teams should begin with the skills used in their regular work, inspect what the client actually discovers, and expand deliberately.
Installation support is excellent
The universal path uses npx skills add, either for everything or a named skill. Claude Code users can add the author's marketplace and install the plugin. The README also gives explicit routes for Gemini CLI, Cursor, Copilot, OpenCode, Codex, Openclaw, and Antigravity. Several clients discover the same .agents/skills location, so one checkout can serve more than one tool.
That cross-client story is a genuine advantage, but behavior will not be identical. Clients have different context limits, trigger logic, command permissions, and instruction precedence. A skill that performs well with one Claude model may not produce the same choices in Codex or Gemini. Issue 84 asks about Codex and Gemini compatibility despite installation instructions being present, which suggests users still need clearer behavioral expectations beyond file discovery.
Updates are a Git pull or client-specific extension update. For team use, pinning a release is safer than tracking main. Otherwise an instruction change can alter review output or generated code without a Go dependency appearing in go.mod.
Evaluations help, but do not settle correctness
The repository publishes per-skill error-rate gaps and an aggregate evaluation table, reporting 3315 of 3395 checks with skills and 1915 without. Those are the project's own results. The README links a separate evaluation document, and the numbers should be read in the context of its tasks, scoring, models, and prompts. They are useful evidence that the author tests changes, not a guarantee of a 41-point improvement on an unrelated codebase.
More importantly, an instruction can be consistent and still be wrong for a team. Open issue 70 argues that the code-style skill's requirement to initialize slices rather than leave them nil contradicts official Go review guidance. The practical answer depends on API serialization needs, but presenting one application-level preference as a universal Go rule is too strong. Another open correction notes that gofumpt does not add missing imports, so disabling goimports leaves a promised automatic-fix workflow incomplete.
These reports are a positive community signal because contributors are checking precise claims. They are also evidence that the collection needs the same review process as any dependency. Official Go docs, tool output, and local architecture decisions outrank a skill file.
How it fits in a real Go workflow
The best use is advisory. Let the relevant skill remind an agent about cancellation, table-driven tests, SQL parameter binding, race detection, profiling, or stable refactoring steps. Then enforce results with gofmt, goimports, go vet, staticcheck or golangci-lint, the race detector, tests, fuzzing, benchmarks, and security tools. Skills improve what the agent considers; executable checks establish what the repository accepts.
Version 1.9.1 shipped on July 26, 2026, and the repository was pushed on August 1. The release corrected benchmark documentation, while August pull requests address import formatting and dependency-update noise. Six open issues and pull requests form a small, current queue.
For Go-heavy agent users, this collection is easy to recommend for a trial. Start with one workflow, compare the agent's decisions with and without the skill, and record local overrides. It is not a substitute for engineering judgment, but it is a well-organized way to give that judgment more specific prompts.