| name | review |
| description | Use when reviewing Go code against Uber's Go Style Guide (https://github.com/uber-go/guide). Activates on explicit request ("review with Uber Go guide", "/uber-go-styleguide:review") — does NOT auto-trigger on `.go` files. Flags violations and groups findings by section, each tied to a detailed rule file under `guidelines/`, `performance/`, `style/`, `patterns/`, or `linting/`. |
Uber Go Style Guide — Review
Code review skill wrapping Uber's Go Style Guide — a pragmatic, opinionated guide covering common Go pitfalls in interfaces, concurrency, error handling, performance, and style. 59 rules are organized into 5 sections. Each rule file is copied verbatim from the pinned Uber source; see ../../UBER_SOURCE.md.
[!NOTE]
This skill complements (does not replace) the sibling google-go-styleguide and go-proverbs-review plugins. Uber's guide is more opinionated than Google's Style Guide on several points (e.g. go.uber.org/atomic, channel-size, start enums at 1). Where they conflict, treat each as independent lenses and decide case-by-case.
When to use
- User explicitly asks for an "Uber Go review" or types
/uber-go-styleguide:review
- User asks about a specific rule by slug ("explain
#error-wrap" / "does this violate #channel-size?") — load the matching rule file directly
This skill does not auto-activate on .go files. Uber's guide is opinionated; the user should choose when to apply it.
How to use
Reviews run as a parallel fan-out of subagents, one per section (not one per rule). Each section subagent reasons coherently about all rules in its topic — so the errors subagent sees error-type, error-wrap, error-name, and error-once together instead of fragmenting tightly coupled rules across separate dispatches.
[!IMPORTANT]
Before any subagent fan-out, ASK the user which model to use for the per-section subagents: opus (highest quality, slowest), sonnet (balanced), or haiku (cheapest, fastest). Wait for their answer — do not pick for them. Pass the chosen model name to every dispatched subagent via the Task tool's model parameter.
Skip this step only for the Single-rule question flow below — it loads one rule file directly in the main thread, no subagents.
Full review
- Identify the Go files in scope and hold only their paths in the main thread.
- For each
actionable section in the index, dispatch a subagent with:
- The section name and path to its folder (e.g.
guidelines/, style/)
- The list of
.go file paths to review
- Instruction: load every
.md file in that folder, read the code, and return findings in the format <file>:<line> — <rule-slug> — <one-sentence observation> or the literal string no findings
- Dispatch all section subagents in parallel (single message, multiple tool calls).
- For the
tooling section (linting/), dispatch a single subagent that verifies the project has a golangci-lint config consistent with Uber's recommendations (see linting/lint.md) and returns pass/fail — no code findings.
- Skip the
philosophical items (intro.md and performance/performance.md) entirely — they inform judgment, not findings.
- Aggregate all subagent results, group by section (and by rule-slug within each), and produce the final report (see Output format).
Partial review
If the user asks to check a specific section ("only Style and Errors") or specific rules ("only #channel-size and #goroutine-forget"), dispatch only the relevant section subagents — and instruct each to focus on the requested rules within its folder.
Single-rule question
If the user asks about one rule specifically ("explain #functional-option" / "does this code violate #container-capacity?"), skip the subagent fan-out: load the single rule file directly in the main thread and answer.
Why this pattern (sections, not individual rules)
- Uber's guide has 59 rules; one subagent per rule is too much fan-out (both in wall-clock cost and in token spend).
- Rules within a section are tightly coupled: all error-handling rules feed each other; all struct-init rules cohere. A section subagent reasons about the whole topic together — fewer false positives, better cross-rule findings.
- Each rule file stays small and focused (copied verbatim from Uber), so a subagent can load its entire section folder without context bloat.
- Main context never holds more than one rule file at a time (only during single-rule questions).
- Parallel execution keeps wall-clock time low — 4 actionable-section subagents + 1 tooling subagent = 5-way fan-out.
Categories
| Category | Meaning |
|---|
actionable | Generates findings during review |
tooling | Verify the tool is wired up (golangci-lint), don't flag code |
philosophical | Informs judgment, no findings emitted |
Section index
Section 0 — Introduction (1 file) — philosophical
intro.md — guide intro, framing, and how Uber applies it. Skipped during review; informs judgment.
Section 1 — Guidelines (26 rules) — actionable
guidelines/ — the bulk of Uber's opinionated rules: interfaces, concurrency, error handling, globals, init/exit, struct tags.
#interface-pointer — Pointers to Interfaces#interface-compliance — Verify Interface Compliance#interface-receiver — Receivers and Interfaces#mutex-zero-value — Zero-value Mutexes are Valid#container-copy — Copy Slices and Maps at Boundaries#defer-clean — Defer to Clean Up#channel-size — Channel Size is One or None#enum-start — Start Enums at One#time — Use "time" to handle time#error-type — Error Types#error-wrap — Error Wrapping#error-name — Error Naming#error-once — Handle Errors Once#type-assert — Handle Type Assertion Failures#panic — Don't Panic#atomic — Use go.uber.org/atomic#global-mut — Avoid Mutable Globals#embed-public — Avoid Embedding Types in Public Structs#builtin-name — Avoid Using Built-In Names#init — Avoid init()#exit-main — Exit in Main#exit-once — Exit Once#struct-tag — Use field tags in marshaled structs#goroutine-forget — Don't fire-and-forget goroutines#goroutine-exit — Wait for goroutines to exit#goroutine-init — No goroutines in init()
Section 2 — Performance (3 rules + 1 intro) — actionable
performance/ — micro-optimizations Uber considers worth the ink.
performance.md (section intro, philosophical — skip)#strconv — Prefer strconv over fmt#string-byte-slice — Avoid repeated string-to-byte conversions#container-capacity — Prefer Specifying Container Capacity
Section 3 — Style (25 rules) — actionable
style/ — formatting, naming, declarations, struct initialization, imports, nesting.
#line-length — Avoid overly long lines#consistency — Be Consistent#decl-group — Group Similar Declarations#import-group — Import Group Ordering#package-name — Package Names#function-name — Function Names#import-alias — Import Aliasing#function-order — Function Grouping and Ordering#nest-less — Reduce Nesting#else-unnecessary — Unnecessary Else#global-decl — Top-level Variable Declarations#global-name — Prefix Unexported Globals with _#struct-embed — Embedding in Structs#var-decl — Local Variable Declarations#slice-nil — nil is a valid slice#var-scope — Reduce Scope of Variables#param-naked — Avoid Naked Parameters#string-escape — Use Raw String Literals to Avoid Escaping#struct-field-key — Use Field Names to Initialize Structs#struct-field-zero — Omit Zero Value Fields in Structs#struct-zero — Use var for Zero Value Structs#struct-pointer — Initializing Struct References#map-init — Initializing Maps#printf-const — Format Strings outside Printf#printf-name — Naming Printf-style Functions
Section 4 — Patterns (2 rules) — actionable
patterns/ — reusable Go patterns Uber endorses.
#test-table — Test Tables#functional-option — Functional Options
Section 5 — Linting (1 rule) — tooling
linting/ — the golangci-lint suite Uber recommends.
#lint — Linting (verify config presence, no per-line findings)
Output format
Group findings under each section, with the rule slug noted on each finding:
### Section N — <section name>
- path/to/file.go:42 — `#rule-slug` — <one-sentence finding>
- path/to/file.go:87 — `#other-slug` — <one-sentence finding>
See: <section>/<rule-slug>.md
End the review with a summary line: total findings, number of distinct rules violated, files touched.
Source
