golang-naming

Enforce Go naming conventions for identifiers, acronyms, and boolean predicates.

5|1|Updated Apr 14, 2026
One-click install
npx skills add https://github.com/omarluq/og-template --skill golang-naming-omarluq
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-naming
Source: https://github.com/omarluq/og-template/tree/main/.agents/skills/golang-naming
Command: npx skills add https://github.com/omarluq/og-template --skill golang-naming-omarluq

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Go naming conventions ensure identifiers communicate intent, avoid ambiguity, and align with community standards, reducing cognitive load for readers and maintainers.

Core Features & Use Cases

  • Guides on identifier naming (MixedCaps, no underscores)
  • Booleans with Is/Has prefixes and proper getter patterns
  • Acronym handling (URL, ID) and constructor naming (New vs NewType)
  • Ensures consistency across packages to avoid stutter and confusion

Quick Start

Apply these naming patterns when writing new Go code or reviewing existing code to ensure consistency.

Frequently Asked Questions about golang-naming

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

FAQPage Schema
What are the standard Go naming conventions for identifiers and acronyms?

Go naming conventions require MixedCaps for identifiers without underscores, all-caps for acronyms like URL or ID, and consistent patterns across packages to ensure code is idiomatic and readable.

How do I name boolean variables and getters in Go?

Boolean predicates in Go should use Is or Has prefixes, and getters should omit the Get prefix to align with community standards and reduce cognitive load for maintainers.

What is the best way to name constructors when creating new Go packages?

Constructors in Go should typically be named New, or NewTypeName when disambiguation is necessary, ensuring clarity and avoiding stutter across package boundaries.

When should I capitalize acronyms in Go identifiers?

Acronyms like URL or ID should be fully capitalized in Go identifiers to maintain consistency and avoid ambiguity when creating or refactoring packages.

How do I avoid stutter and confusion across multiple Go packages?

Ensuring consistency across Go packages involves avoiding stutter by not repeating the package name in identifiers, which aligns with community naming standards and improves readability.