Set up golangci-lint to check Go code for potential problems. Helps select checks, configure project rules, understand warnings, apply available automatic fixes, and document justified exceptions when a warning needs to be suppressed.
Linting best practices and golangci-lint configuration for Golang projects — running linters, configuring .golangci.yml, suppressing warnings with nolint directives, interpreting lint output, and selecting linters. Use when configuring golangci-lint, asking about lint warnings or nolint suppressions, setting up code quality tooling, or choosing linters. Also use when the user mentions golangci-lint, go vet, staticcheck, or revive. Not for wiring a lint step into a GitHub Actions pipeline (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Persona: You are a Go code quality engineer. You treat linting as a first-class part of the development workflow — not a post-hoc cleanup step.
Orchestration mode: Fan out the five sub-agents described in the "Parallelizing Legacy Codebase Cleanup" section (auto-fix, security linters, error handling, style/formatting, code quality) when adopting linting on a legacy codebase, so independent linter categories are fixed concurrently. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.
Modes:
.golangci.yml, choosing linters, enabling CI: follow the configuration and workflow sections sequentially.golangci-lint run --fix on the modified files only while the main agent continues implementing the feature; surface results when it completes.Dependencies:
go install github.com/golangci/golangci-lint/cmd/golangci-lint@latestgolangci-lint is the standard Go linting tool. It aggregates 100+ linters into a single binary, runs them in parallel, and provides a unified configuration format. Run it frequently during development and always in CI.
Every Go project MUST have a .golangci.yml — it is the source of truth for which linters are enabled and how they are configured. See the recommended configuration for a production-ready setup with 48 linters enabled.
# Run all configured linters
golangci-lint run ./...
# Auto-fix issues where possible
golangci-lint run --fix ./...
# Format code (golangci-lint v2+)
golangci-lint fmt ./...
# Run a single linter only
golangci-lint run --enable-only govet ./...
# List all available linters
golangci-lint linters
# Verbose output with timing info
golangci-lint run --verbose ./...
The recommended .golangci.yml provides a production-ready setup with 33 linters. For configuration details, linter categories, and per-linter descriptions, see the linter reference — which linters check for what (correctness, style, complexity, performance, security), descriptions of all 33+ linters, and when each one is useful.
Use //nolint directives sparingly — fix the root cause first.
// Good: specific linter + justification
//nolint:errcheck // fire-and-forget logging, error is not actionable
_ = logger.Sync()
// Bad: blanket suppression without reason
//nolint
_ = logger.Sync()
Rules:
//nolint:errcheck not //nolint//nolint:errcheck // reasonnolintlint linter enforces both rules above — it flags bare //nolint and missing reasonsFor comprehensive patterns and examples, see nolint directives — when to suppress, how to write justifications, patterns for per-line vs per-function suppression, and anti-patterns.
golangci-lint run ./...golangci-lint run --fix ./...golangci-lint fmt ./...issues.new-from-rev in .golangci.yml to only lint new/changed code, then gradually clean up old codeMakefile targets (recommended):
lint:
golangci-lint run ./...
lint-fix:
golangci-lint run --fix ./...
fmt:
golangci-lint fmt ./...
For CI pipeline setup (GitHub Actions with golangci-lint-action), see the samber/cc-skills-golang@golang-continuous-integration skill.
Each issue follows this format:
path/to/file.go:42:10: message describing the issue (linter-name)
The linter name in parentheses tells you which linter flagged it. Use this to:
//nolint:linter-name // reason if it's a false positivegolangci-lint run --verbose for additional context and timing| Problem | Solution |
|---|---|
| "deadline exceeded" | Set or increase run.timeout in .golangci.yml; golangci-lint v2 defaults to no timeout (0) |
| Too many issues on legacy code | Set issues.new-from-rev: HEAD~1 to lint only new code |
| Linter not found | Check golangci-lint linters — linter may need a newer version |
| Conflicts between linters | Disable the less useful one with a comment explaining why |
| v1 config errors after upgrade | Run golangci-lint migrate to convert config format |
| Slow on large repos | Reduce run.concurrency or exclude paths with linters.exclusions.paths / formatters.exclusions.paths |
When adopting linting on a legacy codebase, use up to 5 parallel sub-agents to fix independent linter categories simultaneously:
golangci-lint run --fix ./... for auto-fixable issuessamber/cc-skills-golang@golang-continuous-integration skill for CI pipeline with golangci-lint-actionsamber/cc-skills-golang@golang-code-style skill for style rules that linters enforcesamber/cc-skills-golang@golang-security skill for SAST tools beyond linting (gosec, govulncheck)samber/cc-skills-golang@golang-continuous-integration skill for automated AI-driven code review in CI using these guidelinesNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Measure Go performance by writing benchmarks, examining CPU and memory profiles, and comparing repeated runs with benchstat. Use the results to assess code changes, detect slowdowns in CI, and investigate production performance.
Build, extend, or review Go command-line tools with clear commands, flags, and configuration priorities. It guides output formats, exit codes, shell completion, cancellation, and tests so tools behave predictably in scripts and terminals.
Make Go code easier to read by reviewing line breaks, variable declarations, branching, function parameters, and file organization. Provides concrete style guidance for implementation, code reviews, and project standards where formatting tools alone cannot judge clarity.
Design and review concurrent Go code with clear goroutine ownership, shutdown paths, and error handling. Choose channels, locks, or atomic operations to protect shared data, and structure worker pools with controlled concurrency and cancellation.
Design how Go requests carry cancellation signals, time limits, and request metadata through application layers. Helps investigate work that continues after cancellation, choose suitable context types, and separate background tasks from the request lifecycle.
Set up or improve GitHub Actions pipelines for Go projects. Configure automated tests, code checks, vulnerability scans, dependency update bots, releases, and Docker publishing, with workflow templates and repository settings that control permissions and merge requirements.