Golang Lint
Run a strict golangci-lint profile on Go services and CLIs so correctness and style issues surface before merge or release.
Overview
Golang Lint is an agent skill for the Ship phase that applies a curated golangci-lint v2 configuration for Go correctness and style review.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-lintWhat is this skill?
- golangci-lint v2 config with 5m analysis timeout and concurrency 4
- Correctness stack: govet, staticcheck, unused, errcheck, errorlint, nilerr, and related safety linters
- Style and readability: gocritic, revive, wsl_v5, whitespace, godot, misspell
- Tests included in lint runs; unlimited issues per linter for full visibility
- Opinionated defaults for Go 1.22+ loop vars and modern error wrapping
- 5m lint analysis timeout
- Tests included in lint runs (tests: true)
Adoption & trust: 3.7k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Go repo has inconsistent or minimal linting, so bugs and style debt slip through before CI or production.
Who is it for?
Indie backend devs standardizing golangci-lint on new or existing Go microservices, CLIs, and workers.
Skip if: Non-Go codebases or teams that need a minimal lint set for greenfield prototypes only—trim the enabled linter list first.
When should I use this skill?
You are standardizing Go lint for a repo, aligning agent fixes with golangci-lint, or hardening pre-merge review on backend code.
What do I get? / Deliverables
Your project adopts a documented golangci-lint profile agents and CI can run to enumerate correctness and style issues across production and test code.
- golangci-lint v2 YAML profile ready to commit
- Actionable linter issue list from agent-guided runs
Recommended Skills
Journey fit
How it compares
Skill-delivered linter config—not a hosted MCP or a generic code-review methodology skill.
Common Questions / FAQ
Who is golang-lint for?
Solo and small-team builders writing Go who want an agent to drop in a strict golangci-lint setup without hand-picking dozens of rules.
When should I use golang-lint?
When tightening pre-merge review on a Go service, aligning local lint with CI, or onboarding an agent to fix errcheck and staticcheck findings before Ship.
Is golang-lint safe to install?
It is primarily configuration text; review the Security Audits panel on this page and run lint in a trusted environment since agents may execute golangci-lint via your shell.
SKILL.md
READMESKILL.md - Golang Lint
version: "2" run: concurrency: 4 # Timeout for analysis timeout: 5m # Include test files tests: true issues: max-issues-per-linter: 0 # 0 = unlimited (we want ALL issues) max-same-issues: 50 linters: enable: # correctness - govet # built-in checker: copylocks, printf formats, struct tags, unreachable code - staticcheck # extensive static analysis: deprecated APIs, common mistakes, simplifications - unused # unused variables, functions, types - errcheck # unchecked error returns and type assertions - errorlint # correct use of errors.Is/As and %w wrapping (Go 1.13+) - nilerr # returning nil error when err is non-nil - forcetypeassert # type assertions without comma-ok check - copyloopvar # loop variable copy issues (Go 1.22+) - durationcheck # detect time.Duration * time.Duration bugs - reassign # package-level variable reassignment # style - gocritic # opinionated style: unnecessary conversions, range copies, redundant code - revive # naming conventions, exported types, stuttered package names - wsl_v5 # whitespace and blank line rules for readability - whitespace # trailing whitespace, unnecessary blank lines - godot # exported-symbol comments must end with a period - misspell # common English misspellings in identifiers and comments - dupword # duplicate words in comments and strings (the the, is is) - predeclared # shadowing Go built-ins (len, cap, error) - errname # error type/var naming conventions (ErrFoo, FooError) - asciicheck # non-ASCII identifiers (prevents homoglyph/trojan source attacks) # complexity - gocyclo # cyclomatic complexity threshold - nestif # deeply nested if/else chains - funlen # function length limits (lines and statements) - dupl # code duplication detection # performance - perfsprint # faster alternatives to fmt.Sprintf - unconvert # unnecessary type conversions - ineffassign # assignments to variables never read - goconst # repeated literals that should be constants # security & resources - gosec # security scanner: SQL injection, hardcoded credentials, weak crypto, path traversal - bidichk # dangerous bidirectional Unicode sequences (trojan source CVE-2021-42574) - bodyclose # unclosed HTTP response bodies (connection leaks) - noctx # HTTP requests missing context.Context - containedctx # context.Context stored in struct fields instead of passed as parameter - fatcontext # context.WithValue/WithCancel in loops (unbounded context chain, memory leak) - sqlclosecheck # unclosed sql.Rows and sql.Stmt - rowserrcheck # unchecked sql.Rows.Err() after iteration # logging - sloglint # consistent log/slog code style - loggercheck # key-value pair validation for structured loggers (zap, slog, logr) # testing - testifylint # testify best practices - thelper # test helpers missing t.Helper() - usetesting # use t.Setenv/t.TempDir instead of os equivalents in tests - paralleltest # tests and subtests missing t.Parallel() # modernization & meta - modernize # old patterns replaceable with newer Go features - exptostd # replace golang.org/x/exp/ functions with stdlib equivalents - intrange # range over integer instead of C-style loop (Go 1.22+) - usestdlibvars # use stdlib constants instead of hardcoded values - exhaustive # switch statements not covering all enum values - nolintlint # enforces proper //nolint directive usage disable: - lll # line length — handled by gofmt/gofumpt - prealloc # high fal