go-code-review
Systematic Go code review against community style standards and best practices.
- Covers 15+ review categories: formatting, documentation, error handling, naming, concurrency, interfaces, data structures, security, declarations, functions, style, logging, imports, generics, and testing
- Includes automated pre-review checks via
gofmt,go vet, andgolangci-lintto catch mechanical issues before manual review - Organizes findings by severity (must-fix, should-fix, nit) using a consistent template for clear communication
- References specialized skills for deeper dives into error handling, naming conventions, concurrency patterns, and testing strategies
Go Code Review Checklist
Review Procedure
Use
assets/review-template.mdwhen formatting the output of a code review to ensure consistent structure with Must Fix / Should Fix / Nits severity grouping.
- Run
gofmt -d .andgo vet ./...to catch mechanical issues first - Read the diff file-by-file; for each file, check the categories below in order
- Flag issues with specific line references and the rule name
- After reviewing all files, re-read flagged items to verify they're genuine issues
- Summarize findings grouped by severity (must-fix, should-fix, nit)
Validation: After completing the review, re-read the diff once more to verify every flagged issue is real. Remove any finding you cannot justify with a specific line reference.
Formatting
- gofmt: Code is formatted with
gofmtorgoimports→ go-linting
More from cxuu/golang-skills
go-testing
Use when writing, reviewing, or improving Go test code — including table-driven tests, subtests, parallel tests, test helpers, test doubles, and assertions with cmp.Diff. Also use when a user asks to write a test for a Go function, even if they don't mention specific patterns like table-driven tests or subtests. Does not cover benchmark performance testing (see go-performance).
618go-linting
Use when setting up linting for a Go project, configuring golangci-lint, or adding Go checks to a CI/CD pipeline. Also use when starting a new Go project and deciding which linters to enable, even if the user only asks about "code quality" or "static analysis" without mentioning specific linter names. Does not cover code review process (see go-code-review).
606go-documentation
Use when writing or reviewing documentation for Go packages, types, functions, or methods. Also use proactively when creating new exported types, functions, or packages, even if the user doesn't explicitly ask about documentation. Does not cover code comments for non-exported symbols (see go-style-core).
586go-naming
Use when naming any Go identifier — packages, types, functions, methods, variables, constants, or receivers — to ensure idiomatic, clear names. Also use when a user is creating new types, packages, or exported APIs, even if they don't explicitly ask about naming conventions. Does not cover package organization (see go-packages).
580go-error-handling
Use when writing Go code that returns, wraps, or handles errors — choosing between sentinel errors, custom types, and fmt.Errorf (%w vs %v), structuring error flow, or deciding whether to log or return. Also use when propagating errors across package boundaries or using errors.Is/As, even if the user doesn't ask about error strategy. Does not cover panic/recover patterns (see go-defensive).
571go-concurrency
Use when writing concurrent Go code — goroutines, channels, mutexes, or thread-safety guarantees. Also use when parallelizing work, fixing data races, or protecting shared state, even if the user doesn't explicitly mention concurrency primitives. Does not cover context.Context patterns (see go-context).
570