go-coding — Go standards router

Route the Go task to the right standard and tool (Go 1.27+, golangci-lint v2) — this skill is a router, not an encyclopedia. Every rule targets Go 1.27. On a module whose go directive is older, skip what is marked newer (a Since cell or a (1.NN) note). The tools hold that line: the compiler rejects a newer language feature, go vet's stdversion check (run by go test) reports a newer standard-library symbol, and go fix offers only rewrites the directive allows — so no older variant of a rule is kept. Two principles drive it:

• Deterministic beats prose. Whatever a formatter or linter enforces, run the tool — don't reason it out by hand. The plugin's value is judgment the model lacks, not re-deriving tooling.
• Don't rebuild code intelligence. Ask gopls, not grep, where a symbol is defined, who uses it, who implements it and who calls it: grep matches the name, so it cannot tell a.Close from b.Close, and it cannot see which types satisfy an interface (Go never writes implements). The official gopls-lsp plugin (@claude-plugins-official) provides the LSP tool, which also covers diagnostics, rename and vulncheck. How to ask: Symbol questions below.

Routing table

Symbol questions

Where a Go symbol is defined, who uses it, who implements it, who calls it:

1. With a language-server tool (Claude Code's LSP) whose root is the checkout being changed, use it.
2. Otherwise ask gosym, one call per question: <gosym> -C <checkout> def|refs|impl|calls <Name>. <gosym> is scripts/gosym in this skill's folder: the absolute path the session banner names, or this skill's base directory followed by /scripts/gosym. A brief carries that absolute path. <Name> is a package-level name or Type.Method; a bare name also finds the methods and fields of that name, and a third argument keeps the definitions whose path contains it. It prints each definition as == <file>:<line>:<col>-<col> <Name> <Kind>, then what gopls references (every use, resolved by type), gopls implementation (an interface's types, or the interfaces a type satisfies) or gopls call_hierarchy (callers and callees) answers there, or (n/a: <Kind>) where the question does not apply, with paths relative to the module. A warning that gopls stopped at 100 symbols means the answer may be incomplete: ask again as Type.Method.
3. Without gosym, take the same two steps, cd <checkout> && in each command: gopls workspace_symbol -matcher fuzzy '<Name>$' (gopls lists at most 100 symbols for any query; anchored at the name's end, the list rarely reaches that), then pass the exact hit's first field, unchanged, to gopls references, implementation or call_hierarchy. gopls definition takes the position of a use, not a name; a position off the identifier makes gopls exit 2.
4. If gosym cannot be found or the call is refused, gopls is missing or exits non-zero, or gosym exits 1 or 3, use grep and say so. gosym exit 2 is a wrong call: fix it.

The command line is experimental (https://go.dev/gopls/command-line); gopls help <command> shows what the installed version takes.

Route, then load

The router is an index, not the standard. Before writing or reviewing Go you MUST load the focused skill matching the change — with the Skill tool (go-coding:go-errors, …), not by recalling it:

One load per skill per session is enough; the skill stays in context. Orchestrators dispatching implementer or reviewer subagents carry this table and the Symbol questions section into every brief, with the absolute paths of the checkout or worktree being changed and of gosym — a subagent does not inherit the parent session's skills, and may start in a different folder.

Minimum checklist (when a second load is not affordable)

Apply these even if you load nothing else; they are the rules the focused skills most often catch:

• Wrap with fmt.Errorf("…: %w", err); inspect with errors.Is / errors.AsType and guard the result (ok && v != nil — a typed-nil pointer satisfies the match). Never swallow an error.
• Every guard has a test that fails when the guard is deleted; a "temporarily broke it by hand" check is not evidence — commit it as a can-fail test. Table-driven t.Run with got/want messages.
• range n, min/max, slices/maps, strings.Cut, any; go fix ./... before hand-edits.
• ctx first; no goroutine without an owner that waits for it; t.Context() in tests.
• Run gofmt/gofumpt and golangci-lint run — never reason out what a tool decides.

Tie-breaks (when two valid forms compete)

When both forms pass the tools, decide by the order Google's Go Style Guide gives for readable code: clarity, then simplicity (with its rule of least mechanism: the most standard tool that expresses the idea), then concision, then maintainability, then consistency. Say which attribute decided it; "more idiomatic" on its own is not a reason. Source: https://google.github.io/styleguide/go/guide (normative and canonical).

Writing for the human

Anything a person reads — a PR description, a review comment, a question, a design choice put to them — goes in plain English, not Go shorthand. State the effect before the mechanism ("the request keeps running after the caller gives up", not "ctx leak in the errgroup"), and expand a term the first time it appears or leave it out. Keep it short: a few sentences per point, and a decision they must make gets the options plus a recommendation, not an essay. Identifiers, commands and linter names stay verbatim — it is the prose around them that must be plain.

Authoritative sources (cite, don't guess)

• Effective Go — https://go.dev/doc/effective_go
• Go Code Review Comments — https://go.dev/wiki/CodeReviewComments
• Google Go Style Guide — https://google.github.io/styleguide/go/ — three documents, cite the one a rule comes from: the Guide (https://google.github.io/styleguide/go/guide, normative and canonical: the principles), Style Decisions (https://google.github.io/styleguide/go/decisions, normative: the reviewer rulebook), Best Practices (https://google.github.io/styleguide/go/best-practices, advisory)
• Uber Go Style Guide — https://github.com/uber-go/guide
• Package & toolchain docs — https://pkg.go.dev
• Linter rule catalogues (name the rule, not just the tool) — go vet https://pkg.go.dev/cmd/vet; staticcheck https://staticcheck.dev/docs/checks/; revive https://github.com/revive-lint/revive/blob/master/RULES_DESCRIPTIONS.md; golangci-lint linters https://golangci-lint.run/docs/linters/

For a focused review

Dispatch the go-reviewer agent — a report-only, context-isolated reviewer that loads these skills, applies the review-heuristics catalog and returns severity-ranked findings on a diff or file.

If a workflow already owns the reviewer seat, that reviewer loads the focused skills itself instead — one review seat per diff.

/go-lint-setup scaffolds the reference golangci-lint v2 config into a repo.

Top-level structure adapted from samber/cc-skills-golang (MIT © 2026 Samuel Berthe).