Go Packages

This covers the structural decisions you make when organizing Go code: when to split packages, how to group imports, whether that init() is actually necessary, and where os.Exit belongs (spoiler: only in main). It's opinionated in the right ways, like telling you to avoid util packages and generic names that obscure meaning. The package sizing guidance is genuinely helpful, with a table that asks whether you can describe the package purpose in one sentence. Also includes the run() pattern for CLI tools and flags in snake_case, which catches people off guard if they're coming from other languages. Draws from Google and Uber style guides, so it's not just someone's blog post preferences.

skills.sh installs: 1.3K
GitHub stars: 193
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add cxuu/golang-skills --skill go-packages --agent claude-code

Installs into .claude/skills of the current project.

Files

Go Packages and Imports

Resource Routing

references/IMPORTS.md - Read when grouping imports, using blank imports, dot imports, or import aliases.
references/PACKAGE-SIZE.md - Read when splitting packages, avoiding init, structuring main, or designing CLI flags/subcommands.

When this skill does NOT apply: For naming individual identifiers within a package, see go-naming. For organizing functions within a single file, see go-functions. For configuring linters that enforce import rules, see go-linting.

Package Organization

Avoid Util Packages

Package names should describe what the package provides. Avoid generic names like util, helper, common — they obscure meaning and cause import conflicts.

// Good: Meaningful package names
db := spannertest.NewDatabaseFromFile(...)
_, err := f.Seek(0, io.SeekStart)

// Bad: Vague names obscure meaning
db := test.NewDatabaseFromFile(...)
_, err := f.Seek(0, common.SeekStart)

Generic names can be used as part of a name (e.g., stringutil) but should not be the entire package name.