skills/go-linting/SKILL.md
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).
npx skillsauth add cxuu/golang-skills go-lintingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
More important than any "blessed" set of linters: lint consistently across a codebase.
Consistent linting helps catch common issues and establishes a high bar for code quality without being unnecessarily prescriptive.
.golangci.yml using the configuration belowgolangci-lint run ./...These linters catch the most common issues while maintaining a high quality bar:
| Linter | Purpose | |--------|---------| | errcheck | Ensure errors are handled | | goimports | Format code and manage imports | | revive | Common style mistakes (modern replacement for golint) | | govet | Analyze code for common mistakes | | staticcheck | Various static analysis checks |
Note:
reviveis the modern, faster successor to the now-deprecatedgolint.
Use golangci-lint as your lint runner. See the example .golangci.yml from uber-go/guide.
See
assets/golangci.ymlwhen creating a new.golangci.ymlor comparing your existing config against a recommended baseline.
Create .golangci.yml in your project root:
linters:
enable:
- errcheck
- goimports
- revive
- govet
- staticcheck
linters-settings:
goimports:
local-prefixes: github.com/your-org/your-repo
revive:
rules:
- name: blank-imports
- name: context-as-argument
- name: error-return
- name: error-strings
- name: exported
run:
timeout: 5m
# Install
go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
# Run all linters
golangci-lint run
# Run on specific paths
golangci-lint run ./pkg/...
Beyond the minimum set, consider these for production projects:
| Linter | Purpose | When to enable | |--------|---------|----------------| | gosec | Security vulnerability detection | Always for services handling user input | | ineffassign | Detect ineffectual assignments | Always — catches dead code | | misspell | Correct common misspellings in comments/strings | Always | | gocyclo | Cyclomatic complexity threshold | When functions exceed ~15 complexity | | exhaustive | Ensure switch covers all enum values | When using iota enums | | bodyclose | Detect unclosed HTTP response bodies | Always for HTTP client code |
When suppressing a lint finding, always explain why:
//nolint:errcheck // fire-and-forget logging; error is not actionable
_ = logger.Sync()
Rules:
//nolint:lintername — never bare //nolint//# .github/workflows/lint.yml
name: Lint
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
with:
go-version: stable
- uses: golangci/golangci-lint-action@v6
with:
version: latest
#!/bin/sh
# .git/hooks/pre-commit
golangci-lint run --new-from-rev=HEAD~1
Use --new-from-rev to lint only changed code, keeping the feedback loop fast.
scripts/setup-lint.sh — Generates .golangci.yml and runs initial lintbash scripts/setup-lint.sh github.com/your-org/your-repo
bash scripts/setup-lint.sh --force github.com/your-org/your-repo # overwrite existing
bash scripts/setup-lint.sh --dry-run # preview config
bash scripts/setup-lint.sh --json # structured output
Validation: After generating
.golangci.yml, rungolangci-lint run ./...to verify the configuration is valid and produces expected output. If it fails with a config error, fix and retry.
scripts/setup-lint.shgenerates a minimum config (5 core linters). For established projects, useassets/golangci.ymlas a starting point — it adds gosec, ineffassign, misspell, gocyclo, and bodyclose.
| Task | Command/Action |
|------|----------------|
| Install golangci-lint | go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest |
| Run linters | golangci-lint run |
| Run on path | golangci-lint run ./pkg/... |
| Config file | .golangci.yml in project root |
| CI integration | Run golangci-lint run in pipeline |
| Nolint directives | //nolint:name // reason — never bare //nolint |
| CI integration | Use golangci/golangci-lint-action for GitHub Actions |
| Pre-commit | golangci-lint run --new-from-rev=HEAD~1 |
| When you need... | Use | |------------------|-----| | Error handling coverage | errcheck | | Import formatting | goimports | | Style consistency | revive | | Bug detection | govet, staticcheck | | All of the above | golangci-lint with config |
tools
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).
development
Use when working with Go formatting, line length, nesting, naked returns, semicolons, or core style principles. Also use when a style question isn't covered by a more specific skill, even if the user doesn't reference a specific style rule. Does not cover domain-specific patterns like error handling, naming, or testing (see specialized skills). Acts as fallback when no more specific style skill applies.
development
Use when optimizing Go code, investigating slow performance, or writing performance-critical sections. Also use when a user mentions slow Go code, string concatenation in loops, or asks about benchmarking, even if the user doesn't explicitly mention performance patterns. Does not cover concurrent performance patterns (see go-concurrency).
development
Use when creating Go packages, organizing imports, managing dependencies, or deciding how to structure Go code into packages. Also use when starting a new Go project or splitting a growing codebase into packages, even if the user doesn't explicitly ask about package organization. Does not cover naming individual identifiers (see go-naming).