go-style-guide
Evaluate Go code against Google's Go Style Guide
This skill audits Go source files, packages, or whole codebases against the rules in Google's Go Style Guide, Effective Go, Uber's Go Style Guide, and the user's .golangci.yml. It produces a structured report grouped by category (Naming, Package Organization, Imports, Function Design, Error Handling, Documentation, Variable Declarations, Concurrency, Context, Generics, Tooling & Modernization, Testing) with file:line references and concrete suggested fixes. Findings that are enforced by an enabled linter in .golangci.yml are labeled Violation; those the linter exempts (e.g. staticcheck ST1003, ST1020-1022) are labeled Suggestion.
The goal is to give the user something they can act on, not just a list of issues. Every finding includes the rule it violates, why it matters, and what to change.
When to invoke this skill
- The user explicitly asks for a Go code review, Go style audit, or Google best-practice check.
- The user asks "is this idiomatic", "does this follow Go conventions", or similar.
- The user has just finished writing a substantial Go function, file, or package and wants feedback.
- The user mentions Google's Go style guide or links the URL.
- The user is preparing a Go change for review and wants pre-review feedback.
Do not invoke for: non-Go languages, formatting questions answered by gofmt/goimports (those are deterministic — let the tools handle them), or pure performance tuning (use a Go profiling/benchmarking workflow for that).