---
name: idiomatic-go-patterns-review
description: "Reviews Go code for the habits that cause production trouble: lost error context, leaked goroutines, misused contexts, bloated interfaces, and tangled packages. Use when a Go package or service needs a review for error wrapping, context handling, goroutine leaks, interface design, and package layout. Do not use for porting code from another language to Go or tuning performance with profiles. Related topics: coding, technical."
---

# Idiomatic Go Patterns Review

Reviews Go code for the habits that cause production trouble: lost error context, leaked goroutines, misused contexts, bloated interfaces, and tangled packages.

## When to use

Use this skill when a Go package or service needs a review for error wrapping, context handling, goroutine leaks, interface design, and package layout. Do not use it for porting code from another language to Go or tuning performance with profiles.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Read the code and note every returned error, goroutine start, context parameter, and interface declaration.
3. Check each error is handled or wrapped with %w and compared with errors.Is or errors.As, listing those that are not.
4. For every goroutine, name what stops it and how the context or channel signals that, flagging any with no answer.
5. Judge interfaces and package layout for size, location, and naming, noting where they hinder reuse or testing.
6. Order findings from most to least harmful, each with a corrected snippet, and finish with the three highest-value changes.

## Inputs

- **The code** (longer free text)
- **What it does** (free text, e.g. "Service or library and its role")
- **Go version** (free text, e.g. "1.22")
- **Concerns** (choose any: Error wrapping, Context use, Goroutine lifetimes, Interfaces, Package layout, Concurrency safety, Testing)
- **Review depth** (choose one: Quick scan, Standard, Line by line)

## Output

A findings list ordered by harm, each with line, reason, and corrected snippet, then a closing list of the three changes worth doing first.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Idiomatic Go Patterns Review

Review this Go code the way an experienced maintainer would.

- The code: {{The code}}
- What it does: {{What it does}}
- Go version: {{Go version}}
- Concerns: {{Concerns}}
- Review depth: {{Review depth}}

Check errors first: every returned error should be handled or wrapped with %w and a short message saying what was being attempted, and callers should compare with errors.Is or errors.As rather than strings. Next, context: it should be the first parameter, passed down, and respected by blocking calls and loops. For goroutines, ask for each one who stops it and how, and look for leaks, unguarded shared state, and channels that are never closed or read. For interfaces, prefer small ones defined where they are used, and flag ones defined next to the only implementation. For layout, flag import cycles risk, package names that repeat their contents, and an internal directory that is missing.

List findings from most to least harmful, each with the line, why Go readers would object, and a corrected snippet. End with the three changes that would improve the package most.

## Pitfalls

- Suggesting an interface for every struct, which adds indirection Go readers consider a smell.
- Wrapping errors at every layer so messages repeat the same context five times.
- Approving a goroutine because it works in a test, while nothing ever tells it to stop.