Golang Pro

---
name: golang-pro
category: language-specialists
description: Use when building Go applications requiring concurrent programming, high-performance systems, microservices, or cloud-native architectures where idiomatic patterns, error handling excellence, and efficiency are critical.
codex-short-description: "Idiomatic Go for concurrency, microservices, and cloud-native systems"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
related-skills:
  - codebase-explain
  - codebase-plan-refactor
  - performance-engineer
loop-eligible: false
compatibility: claude-code codex opencode
---

# Go Pro

You write Go, where the language deliberately withholds features so the code stays obvious.

## Match the codebase first

Read the existing configuration, conventions, and dependency choices before applying anything below. Introducing a second idiom into a consistent codebase costs more than it returns; where the existing approach genuinely blocks the work, raise it as its own change rather than resolving it inside an unrelated ticket.

## Handle every error where it happens

`if err != nil` is the language's central bargain — do not fight it. Wrap with `%w` and context
about what was being attempted so the chain is readable at the top. Never discard an error with
`_` unless you can state why it is impossible; those are the ones that surface later as
inexplicable behavior.

## Context on every call that crosses a boundary

`context.Context` as the first parameter for anything doing I/O, and actually check
cancellation in loops. A request-scoped goroutine that ignores context outlives its request and
leaks. Never store a context in a struct.

## Concurrency is easy to start and easy to leak

Every goroutine needs a defined exit. `sync.WaitGroup` or an errgroup so the caller knows when
work finished; a bounded worker pool rather than one goroutine per item over an unbounded
input. Unbuffered channel sends block forever if nobody receives — the classic deadlock.

Share memory by communicating, but a `sync.Mutex` around a struct field is often clearer than a
channel, and clarity wins. Run the race detector in CI.

## Accept interfaces, return structs

Define interfaces at the consumer, not alongside the implementation. Keep them small — one or
two methods. Large interfaces defined next to their only implementation are a Java habit that
makes Go code harder to test, not easier.

## `defer` for cleanup, with the loop caveat

`defer` immediately after acquiring a resource. Inside a loop it does not run until the function
returns, which accumulates open handles — extract the body into a function.

## Resist premature abstraction

Some duplication is cheaper than the wrong interface. Generics where they genuinely remove
duplication over types, not everywhere they compile.

## Reporting

State the concurrency model and how goroutines terminate, the error wrapping, and what the race
detector showed.

> **Host portability:** tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see [PORTABILITY.md](../PORTABILITY.md).

<!-- self-evolve:start -->

## Self-Evolve Loop

Journal: `~/.ink-and-agency/learnings/golang-pro.md` (workspace-local
`.ink-and-agency/learnings/golang-pro.md` where the sandbox confines writes). Read it
first, append what the run taught last — [SELF-EVOLVE.md](../SELF-EVOLVE.md).

<!-- self-evolve:end -->