samber/cc-skills-golang: Go agent skills for Claude Code, Codex and Cursor

What samber/cc-skills-golang actually changes in a Go session

A coding assistant without project context writes Go the way its training data averages out: interfaces where a struct would do, log lines that duplicate error text, table tests that assert nothing. cc-skills-golang is a set of instruction files that a compatible assistant loads on demand, so the model gets Go-specific rules instead of generic ones. The README frames the repository as covering "Go-specific" skills only: language, testing, security, observability. Workflow concerns such as git conventions, CI/CD and PR reviews are explicitly out of scope and pushed to a separate plugin, cc-skills. That split matters. If you expect this repository to tell your assistant how to name a branch, it will not. It is aimed at teams who already route Go work through an agent and want the agent's output to match house conventions for error wrapping, struct design, concurrency and the rest. The README is blunt about provenance: the skills were bootstrapped with Claude Code by distilling the author's Go project commits, then "edited, tested, reviewed and reworked by a human", with the claim that AI-made skills are useless. You cannot verify that claim from the repository alone, but the presence of EVALUATIONS.md and GOLANG-AI-DRIVEN-REVIEW.md at the top level suggests evaluation material ships alongside the skills.

The skill tree: atomic units that cross-reference each other

The README groups skills into four general-purpose clusters. Code Quality holds code-style, naming, error-handling, safety, structs-iface, documentation, lint and security. Architecture and Design holds design-patterns, concurrency, context, dependency-injection, data-structures, database, modernize and refactoring. QA and Performance holds testing, benchmark, performance, troubleshoot and observability. Project Start holds project-layout, popular-libs, cli, continuous-integration, stay-updated, dependency-management, gopls and pkg-go-dev. A fifth band covers framework and library skills: gRPC, GraphQL, Swagger, Google Wire, Uber Dig, Uber Fx, spf13/cobra, spf13/viper, the samber/* family (lo, mo, ro, do, hot, slog, oops) and stretchr/testify. The design intent is stated plainly: these are "atomic, cross-referencing units". A skill can depend on conventions defined in another. The README's own example is that error-handling rules affecting logging live in golang-error-handling, not golang-observability. That is a real architectural constraint rather than a packaging detail. It means the value of the collection comes from the links between files, and a partial install breaks those links. The README also describes token weights per skill: the description field from YAML frontmatter is always loaded for triggering, the full SKILL.md loads only when the skill triggers, and the directory weight covers SKILL.md plus referenced markdown. That is the mechanism that keeps a large collection from filling the context window.

Installing it with the skills CLI and running a first skill

The universal path is the skills CLI, which the README describes as working with any Agent Skills-compatible tool. This command pulls every skill in the repository into your assistant's skill directory, and after it completes the skills should appear as discoverable entries rather than being injected into every prompt.

npx skills add https://github.com/samber/cc-skills-golang --all

To install one skill instead, the README gives the same command with a --skill flag. The example it uses is golang-performance.

npx skills add https://github.com/samber/cc-skills-golang --skill golang-performance

Per-client install: Claude Code, Gemini CLI, Cursor and Codex

Not every assistant has a plugin marketplace, so the README gives a per-client path. Claude Code uses two slash commands, first registering the marketplace then installing the plugin.

/plugin marketplace add samber/cc
/plugin install cc-skills-golang@samber

Gemini CLI has its own extension command, and the README notes it can be updated with gemini extensions update cc-skills-golang.

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

Where the clone-and-discover clients differ

For Cursor, Copilot, OpenCode, Openclaw and Antigravity the README falls back to cloning the repository into a discovery directory. Cursor auto-discovers from .agents/skills/ and .cursor/skills/, so the clone target is the latter. Copilot auto-discovers from .copilot/skills/, and OpenCode from .agents/skills/, .opencode/skills/ and .claude/skills/. Codex is the odd one out: the README points at the codex plugin add command with the cc-skills repository rather than this one, and documents a manual clone into ~/.agents/skills/cc-skills as the fallback. That is a discrepancy worth reading twice before you follow it. If you are on Codex and you want the Go skills specifically, the documented plugin path installs the workflow plugin, not cc-skills-golang. The clone fallback names cc-skills as well. Antigravity is documented as cloning into ~/.antigravity/skills/cc-skills-golang and updating with a git pull in that directory.

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

This is the Cursor form; the same pattern applies to the other discovery-directory clients with their own paths.

The partial-install trap and other limits

The clearest limitation is stated by the project itself: installing only a subset gives a partial and potentially inconsistent view of the guidelines, and the README recommends installing all general-purpose skills together. That is an all-or-nothing posture, and it conflicts with how most people adopt tooling. If you only want the testing conventions, you get them without the error-handling rules they assume. The second limit is scope. This repository is Go only. A polyglot team needs at least two plugins and has to keep their conventions from drifting apart. Third, the skills encode one author's distilled commit history, so they reflect those choices rather than a neutral consensus; where your team disagrees with a convention, the skill will keep pushing the other way until you edit it. Fourth, the README does not document any rollback or uninstall procedure for the CLI path, and it does not describe how skill updates reach a client after the first install. The per-client sections mention update commands for Gemini CLI and Antigravity only. Finally, the README's own warning that AI-made skills are useless, combined with the admission that these were bootstrapped by distilling commits, is a tension the reader has to resolve by inspecting the files.

How this compares with writing your own skill files

The realistic alternative is not another product but a hand-written set of rules in your assistant's project instructions. That approach gives you exact control and no dependency, and it costs you the cross-references. A single rules file has to hold error handling, logging, testing and layout together, and it loads in full every time. The skills format splits that into triggerable units with a small always-loaded description and a larger body that arrives only when relevant, which is the whole reason the token accounting in the README exists. The trade-off runs the other way too: a hand-written file is trivially reviewable in one diff, while this collection spreads conventions across many markdown files with links between them, so changing a house rule can mean editing several skills. The framework and library skills are a second axis of comparison. If your stack is cobra, viper, testify or the samber/* libraries, the collection already carries rules for them; if it is not, those skills are dead weight in the install.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-07. The most recent release listed is v2.0.0 from 2026-08-20, preceded by v1.9.1 on 2026-07-26 and v1.9.0 on 2026-07-16. The cadence is frequent, and the v2.0.0 major bump signals that skill content or structure can change in ways that are not backward compatible. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; that is a summary of the licence text, not legal advice, and your counsel should confirm how it interacts with your distribution model. Upgrade cost depends on your install path. Marketplace users re-run the plugin install or update command. Clone-based users run git pull in the clone directory, which the README documents for Antigravity. If you have edited any skill locally to match house conventions, a pull will conflict, and the README does not describe a supported way to carry local overrides across releases. Treat local edits as a fork you maintain yourself.

Editorial conclusion

Adopt it if you already run a Go codebase through an Agent Skills-compatible assistant and want its suggestions to follow one set of Go conventions instead of the model's defaults. Skip it if your assistants do not read skill directories, or if you only want one narrow skill, because the repository states that installing a subset gives a partial and potentially inconsistent view. Before relying on it, read the skill you care about in skills/ and confirm which other skills it cites, since error-handling rules that affect logging are documented as living in golang-error-handling rather than golang-observability.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. samber/cc-skills-golang on GitHub