golang-naming

Applies Go naming conventions for packages, constructors, interfaces, errors, enums, and tests.

Updated May 9, 2026
One-click install
npx skills add https://github.com/LuminaVault/LuminaVaultShared --skill golang-naming-luminavault
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-naming
Source: https://github.com/LuminaVault/LuminaVaultShared/tree/main/.agents/skills/golang-naming
Command: npx skills add https://github.com/LuminaVault/LuminaVaultShared --skill golang-naming-luminavault

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go codebases often accumulate inconsistent or non-idiomatic names — stuttering constructors like NewClient(), ALL_CAPS constants, bare boolean fields, or capitalized error strings — that confuse readers and break tooling expectations. This Skill provides the complete set of Go naming conventions so new code, reviews, and refactors follow community standards. ## Core Features & Use Cases - Comprehensive naming rules: Covers packages, files, variables, booleans, receivers, acronyms, constructors, getters/setters, functional options, interfaces, structs, constants, enums, sentinel errors, and test functions. - Common mistake catalog: Maps frequent anti-patterns (Get-prefix getters, snake_case identifiers, util/helper packages, missing zero-value enum sentinels) to their idiomatic fixes. - Detailed reference guides: Five in-depth reference documents on packages/files, identifiers, functions/methods, types/errors, and test naming for deeper consultation. - Use Case: When writing a new Go package like dbpool, use this Skill to correctly name the constructor New() instead of NewPool(), place a StatusUnknown sentinel at iota 0, and prefix sentinel error strings with the package name. ## Quick Start Review my Go package and fix any naming that violates Go conventions, including constructors, error strings, boolean fields, and enum values.

Frequently Asked Questions about golang-naming

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How should I name a Go constructor function?▼

Name it New() when the package exports a single primary type, so callers write apiclient.New(). Use NewTypeName() only when the package has multiple constructible types, like http.NewRequest and http.NewServeMux.

What are the Go naming conventions for error strings?▼

Error strings must be fully lowercase including acronyms, with no trailing punctuation, because they are often wrapped with fmt.Errorf. Sentinel errors should include the package name as prefix, such as "mypackage: not found".

Should Go getters use the Get prefix?▼

No, Go omits the Get prefix on value getters, so user.Name() not user.GetName(). Boolean predicates are the exception and keep Is/Has/Can prefixes, like IsHealthy() bool, following standard library patterns.

How do I name Go enum values with iota?▼

Prefix enum values with the type name, like StatusReady, and place an explicit Unknown or Invalid sentinel at iota 0. This catches uninitialized variables, since a zero-value var would otherwise silently map to a real state.

Why should I avoid package names like util or helpers in Go?▼

Generic names like util, helper, common, or base communicate nothing about content and cause import collisions. Go packages should be lowercase, singular, single-word names that describe their specific purpose, like email or currency.

When should I use import aliases in Go?▼

Only on actual name collisions, such as crypto/rand versus math/rand where you alias one as mrand. Aliasing for readability or preference adds cognitive load without resolving any ambiguity.