golang-code-style Skill Review: 9,921 Bytes of Go Opinion and One Disputed MUST
The slice rule in samber's golang-code-style skill is one sentence: "Slices and maps MUST be initialized explicitly, never nil." The Go project's own Code Review Comments wiki recommends the opposite default, and an issue saying so has been open for 117 days with no reply from the repo owner. That's the thread I pulled on. The skill is a 9,921-byte SKILL.md in a repo with 3,692 stars and 46 skills.
I read every file in the skill's directory, the repo's issues and Hacker News. I did not run the skill, so nothing below is a measured cost. Token figures are file bytes divided by 4, an estimate you can redo by hand.
TL;DR / Key Takeaways
- The
golang-code-styleSKILL.md is 9,921 bytes, roughly 2,480 estimated tokens (bytes ÷ 4); with its one reference file, details.md (2,722 bytes), the loaded set is 12,643 bytes, roughly 3,161 estimated tokens. - The samber/cc-skills-golang repository has 3,692 GitHub stars, 247 forks, an MIT license and 46 SKILL.md files totalling 510,845 bytes (about 127,711 estimated tokens if all were loaded).
- The maintainer's own evaluation reports 66 of 83 assertions passing with the skill (80%) against 33 of 83 without it (40%), human-graded on Claude Sonnet 4.6 for skill version 1.0.0; the skill is now 1.3.0. It is a maintainer claim, not an independent result.
- The skill's rule that slices "MUST be initialized explicitly, never nil" has been disputed in GitHub issue #70 since 2026-07-03, 117 days at review time, and the Go Code Review Comments wiki calls the nil slice "the preferred style".
- The skill's frontmatter pre-approves Edit, Write and Bash(git:*) for the turn that invokes it, broader than a style review needs.
What the skill actually says
SKILL.md uses MUST 7 times and SHOULD 4 (grep count). Most are sound Go habits: early returns, no else after a return, named fields in literals, four parameters or fewer, "Unexport aggressively". Three lines carry the character of the file:
"Slices and maps MUST be initialized explicitly, never nil."
"Function calls with 4+ arguments MUST use one argument per line — even when the prompt asks for single-line code"
"When ignoring a rule, add a comment to the code."
The second overrules an explicit user instruction over a formatting preference. The third is the best line in the file.
The frontmatter declares allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent and a paths filter of **/*.go. A "Parallelizing Code Style Reviews" section fans out up to 5 sub-agents. A "Community default" note lets a company skill supersede it, a sensible escape hatch.
What it costs you in context
Arithmetic from file sizes, not a session measurement: bytes ÷ 4.
| File | Bytes | Est. tokens (bytes ÷ 4) | When it's in context |
|---|---|---|---|
Frontmatter description | 484 | 121 | Always (trigger text) |
SKILL.md | 9,921 | 2,480 | When the skill triggers |
references/details.md | 2,722 | 681 | Linked twice from SKILL.md as "[Details]" |
| Loaded set (SKILL.md + details.md) | 12,643 | 3,161 | |
evals/evals.json | 35,853 | 8,963 | Maintainer test cases; SKILL.md mentions it 0 times |
| Whole directory (3 files) | 48,496 | 12,124 |
The README lists 2,358 tokens for SKILL.md and 2,974 for the directory. My bytes ÷ 4 figures run about 5 to 6% higher, the gap you'd expect between a divisor and a real tokenizer.
The repo-level number matters more, since the skill sits beside 45 others. The 46 frontmatter descriptions total 27,980 bytes, about 6,995 estimated tokens by my regex parse. The README says the recommended skills "load ~1,100 tokens of descriptions at startup"; the Description column for its 14 starred skills sums to 1,743. Issue #81 is one user hitting that wall in Codex.
What the community reports
I found no hands-on write-up of this specific skill. The five items below are about the repo, and only the first touches this skill's content. That's thin.
| Source | Date | What was reported | Link |
|---|---|---|---|
| GitHub issue #70 (open) | 2026-07-03 | YouToco says the never-nil slice rule contradicts the Go Code Review Comments wiki. 3 comments: ccoVeille "I tend to agree."; two identical posts from another account. No reply from the owner. | issue 70 |
| GitHub issue #81 (open) | 2026-07-16 | matrixik asks for shorter descriptions, quoting a Codex notice that they "were shortened to fit the 2% skills context budget". 0 comments. | issue 81 |
| GitHub issue #35 (closed) | 2026-05-07 | wauxhall claimed "TONS of mistakes" in several skills, naming golang-troubleshooting and golang-benchmark (not this one). The maintainer asked for specifics and closed it on 2026-05-23. | issue 35 |
| Hacker News story, 3 points | 2026-03-23 | Posted by the repo author, whose comment claims "a 43% reduction in Go errors and bad practices" on Opus 4.6 for the whole collection. The one reply: "Nice cheatsheet." | HN 47487741 |
| Hacker News comment | 2026-08-14 | User agonux, in the 444-point thread "Go is an ideal language for AI-assisted software engineering": links this repo and spf13/go-skills, then says golangci-lint and the tools already integrated with Go cover a lot of the same ground. | HN 49301458 |
The 43% figure and the README's eval are the maintainer's claims. The README also concedes "I estimate that 50% of golang-naming and golang-code-style overlap with linters (golangci-lint)"; the HN commenter says the same from outside.
On issue #70: the Go wiki (Code Review Comments, fetched this run) says "the nil slice is the preferred style", with an exception for "limited circumstances" such as "encoding JSON objects". The skill's JSON worry is real at API boundaries; the dispute is the blanket MUST. At commit 246b6c4 (2026-10-23) the rule still reads "never nil".
The eval, read carefully
EVALUATIONS.md reports 24 evals and 83 assertions on Claude Sonnet 4.6, graded "Human-as-judge" (not stated by whom), for skill version v1.0.0. The frontmatter is now 1.3.0 and the current evals.json holds 88 assertions, so the score describes an older file. The summary table's Concern column flags this skill as "Low with-skill score". The assertions mirror the rules, so a pass shows the model follows a rule, not that it's right. In eval 2 the never-nil assertions passed with and without the skill. In eval 13, an adversarial "return nil, caller checks" prompt, the skill scored 0 of 3 and so did the baseline.
How to install it
Copied from the repo README; I did not execute them.
# any Agent Skills-compatible tool: all 46 skills
npx skills add https://github.com/samber/cc-skills-golang --all
# a single skill (README's example uses golang-performance; swap the name)
npx skills add https://github.com/samber/cc-skills-golang --skill golang-code-style
# Claude Code plugin
/plugin marketplace add samber/cc
/plugin install cc-skills-golang@samber
# Gemini CLI
gemini extensions install https://github.com/samber/cc-skills-golang
One catch: SKILL.md points at 8 other skills (15 references), and the README says "Installing only a subset will give you a partial and potentially inconsistent view of the guidelines."
Where it earns its keep, and where it doesn't
It earns its keep on Go codebases with no written style guide and a loose linter setup. Early returns, named fields, %q in errors and "unexport aggressively" are good defaults for agent-written Go, all overridable.
It earns little if you already run a strict golangci-lint config; the author's own estimate is about half overlap. It's also a poor fit if you follow the Go wiki's nil default, because you'd pay context for a rule you then override.
The criticisms are concrete:
- A contested MUST sat unanswered for 117 days. An agent follows it as written.
- The file contradicts itself. The rule says conditions with 3+ operands MUST be extracted into named booleans, yet SKILL.md's own example has four operands and leaves
permissions.Contains(PermOverride)inline. details.md extracts it ashasOverride. - The tool grant is broad. Claude Code's docs say
allowed-toolslets Claude use tools "without asking permission during the turn that invokes this skill". Edit, Write and every git subcommand is a lot for a style review. It clears at your next message. - The eval is stale. It scores v1.0.0 with 83 assertions; the repo ships 1.3.0 and 88.
- The fan-out is unpriced. Up to 5 sub-agents could multiply cost; the file gives no figure and we didn't run it.
FAQ
What does the golang-code-style skill do?
It sets Go style rules linters handle poorly: early returns, no unnecessary else, named fields, one argument per line for calls with four or more arguments, and pointer versus value. It ships a 9,921-byte SKILL.md plus a 2,722-byte details.md, and can fan out up to 5 sub-agents.
How much context does golang-code-style use?
By file-size arithmetic (bytes ÷ 4, an estimate, not a measured session cost): about 2,480 tokens for SKILL.md and 3,161 with details.md. The 484-byte description, always loaded, is about 121.
Is the never-nil slice rule correct?
It's disputed. The Go wiki prefers a nil slice and allows a non-nil empty one in limited cases such as JSON encoding. Issue #70 raises this and was still open on 2026-10-28. The JSON concern is real at API boundaries; as a blanket MUST it reverses the wiki default.
How do I install golang-code-style?
Run npx skills add https://github.com/samber/cc-skills-golang --skill golang-code-style, or install the Claude Code plugin with /plugin marketplace add samber/cc then /plugin install cc-skills-golang@samber. The README recommends installing the related skills together.
Skill by samber, MIT licensed (per the GitHub API and the SKILL.md frontmatter). Source: github.com/samber/cc-skills-golang, reviewed at commit 246b6c4 (2026-10-23). Review date October 28, 2026. Quoted lines are short excerpts for review purposes. Star counts and issue states are as of this date, and community reception shifts over time. Token figures are estimates from file size.