samber/cc-skills-golang: Go Agent Skills as On-Demand Context
🧑🎨 A collection of Golang agentic skills that works
At a glance
- What is it?
- A MIT-licensed collection of Go-specific agent skills that load on demand into Claude Code, Codex, Gemini, Copilot, Cursor and other Agent Skills clients. The design is sound and the cross-referencing is deliberate, but the skills are written as atomic units, so installing a subset gives you a partial rulebook.
- Who is it for?
- Adopt it if you already run an Agent Skills-compatible assistant on a Go codebase and you install the general-purpose set together rather than cherry-picking single skills, because the README states that a skill may reference conventions defined in another and a subset produces an inconsistent view.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: Go conventions that a general coding assistant does not carry
A general-purpose coding assistant knows Go syntax and can write a handler. What it does not reliably carry is your project's position on error wrapping, where logging rules live relative to error handling, which dependency injection library the team picked, or how the project lays out packages. The repository describes itself as a collection of Go-specific skills covering language, testing, security and observability, and it is explicit that it does not cover dev workflow concerns such as git conventions, CI/CD or PR reviews, pointing to a separate cc-skills plugin for those. The intended reader is a Go engineer already using an agentic coding assistant who wants the assistant's default behaviour nudged toward a specific set of conventions rather than generic ones. The README notes the skills were bootstrapped with Claude Code by distilling the author's Go project commits and then edited, tested, reviewed and reworked by a human, which is a claim about provenance rather than a guarantee about fit for your codebase.
Skills as on-demand context, not a system prompt
The README's definition is the mechanism: agent skills are reusable instruction sets loaded on demand so they do not bloat your context. That is the whole architectural idea, and it has a measurable cost model attached. The skills table in the README tracks three token figures per skill: the weight of the description field from YAML frontmatter, which is always loaded into Claude's context for skill triggering; the weight of the full SKILL.md file, loaded when the skill triggers; and the weight of every file in the skill directory including SKILL.md and referenced markdown. Those three numbers describe the actual data flow. The description sits resident and decides whether the skill fires. The body arrives only after triggering. Anything the body references arrives after that. This is why the repository can ship dozens of skills without a permanent context penalty, and it is also why a badly written description is the failure point rather than a badly written body.
Installing with the skills CLI versus per-client plugin commands
The universal path is the skills CLI, which the README says works with any Agent Skills-compatible tool. Installing everything takes one command: npx skills add https://github.com/samber/cc-skills-golang --all. A single skill uses the same command with a flag, for example npx skills add https://github.com/samber/cc-skills-golang --skill golang-performance. Per-client paths differ. Claude Code uses /plugin marketplace add samber/cc followed by /plugin install cc-skills-golang@samber. Gemini CLI uses gemini extensions install https://github.com/samber/cc-skills-golang and updates with gemini extensions update cc-skills-golang. Codex uses codex plugin add github:samber/cc-skills and codex plugin update cc-skills. Several clients are served by cloning into a discovery directory instead: ~/.cursor/skills/cc-skills-golang for Cursor, ~/.copilot/skills/cc-skills-golang for Copilot, ~/.agents/skills/cc-skills-golang for OpenCode, ~/.openclaw/skills/cc-skills-golang for Openclaw, and ~/.antigravity/skills/cc-skills-golang for Antigravity, which updates with cd ~/.antigravity/skills/cc-skills-golang && git pull. Note that the Codex plugin command in the README points at samber/cc-skills, not samber/cc-skills-golang, and the README itself describes a manual clone fallback for that path.
Atomic units that cross-reference each other, and why subsets break
This is the design decision worth arguing about. The README states the skills are designed as atomic, cross-referencing units, and gives a concrete example: error-handling rules that affect logging live in golang-error-handling, not in golang-observability. It then states plainly that installing only a subset gives a partial and potentially inconsistent view of the guidelines, and recommends installing all general-purpose skills together. That is an honest warning, and it is also a real constraint on adoption. The single-skill install flag exists and works, but the repository's own position is that using it selectively degrades the result. The catalogue is grouped into Code Quality (code-style, naming, error-handling, safety, structs-interfaces, documentation, lint, security), Architecture and Design (design patterns, concurrency, context, dependency injection, data structures, database, modernize, refactoring), QA and Performance (testing, benchmark, performance, troubleshoot, observability), Project Start (project-layout, popular-libs, cli, continuous-integration, stay-updated, dependency management, gopls, pkg-go-dev), plus framework and library skills for grpc, graphql, swagger, google-wire, uber-dig, uber-fx, spf13-cobra, spf13-viper, the samber/* family and stretchr-testify. The README's own legend marks skills as recommended, published, work in progress or to-do, which means the catalogue is not uniformly finished.
Where this is the wrong tool
The clearest boundary is the one the README draws itself: this repository is Go-specific. If you need git conventions, CI/CD or PR review behaviour, this is not the plugin, and the README directs you to cc-skills instead. A second boundary is client support. Every install path assumes an Agent Skills-compatible assistant; if your team's tooling does not read a skills directory or a plugin marketplace, none of the commands above do anything useful. A third is the subset problem described in the previous section, which cuts against the common instinct to install only the two or three skills that sound relevant. There is also a provenance caveat the README states rather than hides: the skills were bootstrapped by distilling one author's Go project commits. Distilled conventions reflect a particular set of projects. If your codebase has settled on different answers for logging, dependency injection or package layout, the skills will push the assistant toward the distilled position, and you will be arguing with your own tooling. The README does not describe a mechanism for overriding a skill's rules beyond the overridable marker in its legend, and the truncated material does not show what that marker controls.
The alternative: one large house style document
The obvious alternative is not another skills repository. It is a single CONTRIBUTING.md or AGENTS.md file in your own repo that states your Go conventions once, in your own words, with your own examples. The difference in approach is context economics. A house style file is always loaded, so it costs tokens on every request whether or not the task touches error handling, and it grows monotonically as you add rules. The skills model inverts that: descriptions stay resident and cheap, bodies load only when the task matches, and a skill about benchmarks costs nothing during a refactor. The trade is control. A house style file is yours and says exactly what you decided. These skills say what the author distilled, and the README's own advice is to install them as a set rather than picking individual rules, which is the opposite of how you would edit your own document. If your conventions are already written down and your assistant reads them reliably, the marginal value here is coverage of topics you have not written about yet: gopls usage, benchmark structure, or the samber/* libraries, for instance.
Maintenance, versioning and the MIT licence
The repository is MIT-licensed, which permits reuse and modification, including in commercial settings, subject to the licence terms; that is a statement about the licence text, not legal advice, and you should read the file if the distinction matters to your organisation. Versioning is visible: v2.0.0 landed on 2026-08-20, following v1.9.1 on 2026-07-26 and v1.9.0 on 2026-07-16, with the last push to the default branch on 2026-09-07. A major version bump after a run of minor releases is worth checking against your pinned install, particularly for the clone-based clients where updating means a git pull rather than a versioned fetch. Update commands differ per client and are documented: gemini extensions update cc-skills-golang, codex plugin update cc-skills, and the Antigravity git pull shown earlier. The skills CLI and Claude Code plugin paths are not shown with an explicit update command in the supplied material. The recurring cost is not the install, it is re-reading the skills table after an upgrade to see which token weights moved and which entries shifted between the published, work-in-progress and to-do states.
Editorial conclusion
Adopt it if you already run an Agent Skills-compatible assistant on a Go codebase and you install the general-purpose set together rather than cherry-picking single skills, because the README states that a skill may reference conventions defined in another and a subset produces an inconsistent view. Skip it if your team does not use a skills-capable client, or if you want workflow skills for git conventions, CI/CD and PR review, since this repository covers Go only and points elsewhere for those. Before adopting, check the SKILL.md token weights in the skills table against your context budget and confirm your client actually discovers the directory it auto-scans, for example ~/.cursor/skills/cc-skills-golang or ~/.agents/skills/cc-skills-golang.
Community notes