Go Development Patterns

Required Workflow

For reviews, invoke related skills: security-audit (OWASP), enterprise-readiness (OpenSSF/SLSA), github-project (branch protection).

Core Principles

Type Safety

• Avoid: interface{} (use any), sync.Map, scattered type assertions, reflection
• Prefer: Generics [T any], errors.AsType[T] (Go 1.26), concrete types
• Run go fix ./... after upgrades

Consistency

• One pattern per problem domain
• Match existing codebase patterns
• Refactor holistically or not at all
• Config precedence: defaults < config file < env vars < flags

Testing

• Build tags isolate test tiers: unit (default), integration, e2e
• Always use t.Parallel(), t.Helper(), table-driven subtests
• Use log/slog directly -- never wrap it in custom Logger interfaces

Conventions

• Naming: ID, URL, HTTP (not Id, Url, Http) — not tool-enforced (ST1003 is off by default)
• Error wrapping: fmt.Errorf("failed to process: %w", err)

References

Git hooks: ls lefthook.yml 2>/dev/null && lefthook install || echo "Add lefthook — see references/lefthook-template.md"

Load as needed:

Quality Gates

Run before completing any review:

golangci-lint run --timeout 5m    # Linting
go vet ./...                       # Static analysis
staticcheck ./...                  # Additional checks
govulncheck ./...                  # Vulnerability scan
go test -race ./...                # Race detection

Stdlib Vulnerability Fixes

When govulncheck reports stdlib vulnerabilities: check fix version via vuln.go.dev, update go X.Y.Z in go.mod, run go mod tidy.

Contributing: Submit improvements to https://github.com/netresearch/go-development-skill