go-clean-architecture
Use when scaffolding or refactoring a Go service into a framework-agnostic clean (hexagonal) architecture: Domain, Usecase, Repository, Delivery layers, inward…
Use when writing or reviewing Go documentation — godoc comments on packages, types, functions, methods, sentinel errors; runnable Example tests; README/CONTRIBUTING/CHANGELOG. Covers the project-type detection (library vs application) that decides which docs are needed, comment
$ npx -y skills add muratmirgun/gophers --skill go-documentation --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/go-documentationContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when writing or reviewing Go documentation — godoc comments on packages, types, functions, methods, sentinel errors; runnable Example tests; README/CONTRIBUTING/CHANGELOG. Covers the project-type detection (library vs application) that decides which docs are needed, comment
name: go-documentation description: "Use when writing or reviewing Go documentation — godoc comments on packages, types, functions, methods, sentinel errors; runnable Example tests; README/CONTRIBUTING/CHANGELOG. Covers the project-type detection (library vs application) that decides which docs are needed, comment grammar (start with name, full sentences), what to document vs what to skip, and Example test conventions. Apply proactively when introducing exported names, even if documentation was not requested." license: MIT compatibility: "Designed for Claude Code or similar AI coding agents. Works on any Go version; new-style godoc headings/links need Go 1.19+." allowed-tools: Read Edit Write Glob Grep Bash(go:*)
Documentation in Go is part of the API. Doc comments compile into `go doc`, `pkg.go.dev`, and IDE tooltips, so the rules exist to make those views readable. Code says *what*; comments say *why*, *when*, and *what can go wrong*.
1. **Every exported name has a doc comment.** Packages, types, functions, methods, constants, variables. 2. **Doc comments start with the name** (`// Encode writes ...`). Full sentences, capitalised, end with a period. 3. **Document non-obvious behaviour.** Restating the signature is noise. 4. **Mark deprecations explicitly** with a `Deprecated:` paragraph. 5. **Examples are tests** — runnable `Example*` functions in `_test.go` files with `// Output:` blocks are verified by `go test`. 6. **Every package has exactly one package comment** above the `package` clause in one file (`doc.go` if long).
Detect this first — it changes the doc surface area.
| Signal | Project type | Docs to focus on | |---|---|---| | No `main` package, intended to be imported | **Library** | godoc, `Example*` tests, README usage examples, pkg.go.dev rendering | | Has `main` package, `cmd/` directory, ships a binary or Docker image | **Application/CLI** | Install instructions, `--help` text, config docs | | Both (libraries that ship CLI tools) | Both | All of the above |
Universal: doc comments on exported names, package comment, README, LICENSE, CONTRIBUTING (recommended), CHANGELOG (recommended).
> Read [references/godoc-grammar.md](references/godoc-grammar.md) for the comment grammar, headings/lists, deprecation markers, and full examples.
// Encode writes the JSON encoding of req to w. // It returns an error if req contains a non-serialisable field. func Encode(w io.Writer, req *Request) error
Rules:
Unexported names with non-obvious behaviour should also be commented — those comments are for maintainers, not godoc.
| Topic | Document when | Skip when | |---|---|---| | Parameters | edge cases, units, ranges | type/name already say it | | Context | behaviour differs from standard cancellation | standard `ctx.Err()` propagation | | Concurrency | ambiguous (e.g., a read that mutates internal state) | read-only is safe by default; mutation is unsafe by default | | Cleanup | always — `defer Close()`, `Stop()` requirements | — | | Errors | sentinel values (`ErrNotFound`), error types (use `*PathError` pointer) | — | | Named returns | multiple values of the same type | type alone is clear | | Side effects | always — file writes, network calls, init-time work | — |
Restating signatures is the most common waste:
// Bad — restates what you can see
// SetName sets the name.
func (u *User) SetName(name string) { ... }
// Good — explains the why and the constraints
// SetName sets the user's display name. Returns ErrInvalidName
// if name is empty or longer than MaxNameLen.
func (u *User) SetName(name string) error { ... }Every package has exactly one. Place it above the `package` clause in one file. For long descriptions, use a dedicated `doc.go`.
// Package store provides a transactional key-value store backed by // SQLite. It is safe for concurrent use; see (*Store).BeginTx for // transaction semantics. package store
For `main` packages, use the binary name:
// The migrate command applies SQL migrations from disk to a database. package main
func ExampleEncode() {
var buf bytes.Buffer
_ = Encode(&buf, &Request{ID: "abc"})
fmt.Println(buf.String())
// Output: {"id":"abc"}
}Naming:
`go test` runs these and verifies the `// Output:` line matches. They appear in godoc attached to the named symbol — the best documentation is the kind the compiler keeps honest.
> Read [references/examples-and-readme.md](references/examples-and-readme.md) for `Example*` patterns, the canonical README outline, and CONTRIBUTING/CHANGELOG templates.
Sentinel errors: document on the variable, not on each return.
// ErrNotFound is returned when no record matches the query.
var ErrNotFound = errors.New("store: not found")Error types: document with the **pointer form** so `errors.Is`/`errors.As` examples match.
// PathError records the operation and path that caused an error.
// Use errors.As(err, new(*PathError)) to inspect the fields.
type PathError struct { Op, Path string; Err error }| Anti-pattern | Why it hurts | Do this instead | |---|---|---| | `// SetName sets the name.` | restates signature, no value | explain constraints, side effects, errors | | `// TODO: improve this` with no owner/date | forever-todo | link to issue or remove | |
26 production-grade Go skills for Claude Code, Gemini CLI, and opencode. Battle-tested patterns from the Go community — codified as triggerable AI skills.
Repo: muratmirgun/gophers
Use when scaffolding or refactoring a Go service into a framework-agnostic clean (hexagonal) architecture: Domain, Usecase, Repository, Delivery layers, inward…
Invoke this skill to systematically review a Go change against community style standards before merging. Walks the diff topic by topic — formatting, errors,…
Use when writing or reviewing Go code for clarity, formatting, control flow, variable declarations, switch usage, and function design. Covers the priority…
Use when writing or reviewing concurrent Go code — goroutines, channels, select, mutexes, atomics, errgroup, singleflight, worker pools, or fan-out/fan-in…
Use when designing, propagating, or debugging context.Context flow in Go — first-parameter placement, deadlines and cancellation, request-scoped values,…
Use when writing conditionals, loops, switches, type switches, or blank-identifier patterns in Go. Covers if-with-initialization, guard clauses, early returns,…