eduardo-sl/go-agent-skills

go-ci

Continuous integration for Go projects: GitHub Actions pipelines, caching, golangci-lint setup, test/coverage gates, vulnerability scanning, build matrices, and Makefile targets.

View source

How to use

  1. Copy the installation command and review the source package before installing it in your own agent environment.
  2. Check the source document for required tools, credentials and supported hosts.
  3. Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/eduardo-sl/go-agent-skills --skill go-ci

Before you start

  • Installation does not include a model subscription, API allowance or permission to access your files.
  • Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

Go CI

A Go pipeline has exactly four gates: build, vet/lint, test with race detector, vulnerability scan. Everything else is optimization.

1. Baseline GitHub Actions Workflow

yaml
name: ci
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod   # single source of truth
          cache: true               # caches module + build cache
      - run: go build ./...
      - run: go vet ./...
      - run: go test -race -shuffle=on -coverprofile=coverage.out ./...

  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - uses: golangci/golangci-lint-action@v6
        with:
          version: latest

  vuln:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - run: go run golang.org/x/vuln/cmd/govulncheck@latest ./...

Key decisions baked in:

  • go-version-file: go.mod — never hardcode the Go version in two places.
  • cache: true on setup-go handles module and build caches; do not add

manual actions/cache steps for Go on top of it.

  • -race -shuffle=on — races and order-dependent tests fail in CI, not

production.

  • permissions: contents: read — least privilege by default.
  • Lint in a separate job — it fails fast and parallelizes with tests.

2. golangci-lint Configuration

Commit a .golangci.yml; an unconfigured linter is noise:

yaml
linters:
  enable:
    - errcheck      # unchecked errors
    - govet
    - staticcheck
    - errorlint     # %w misuse, == on errors
    - gosec         # security patterns
    - revive        # style, replaces golint
    - misspell
issues:
  exclude-rules:
    - path: _test\.go
      linters: [gosec]  # test code may use weak randomness etc.

Start from this small set and add linters deliberately. Enabling everything produces hundreds of findings nobody triages. nolint directives require a reason: //nolint:gosec // G404: jitter, not crypto.

3. Build Matrix — Only When You Ship It

yaml
strategy:
  matrix:
    go: ['1.23', '1.24']         # only versions you support
    os: [ubuntu-latest, macos-latest, windows-latest]

Libraries: test the two newest Go versions (the Go team supports two). Services deployed on Linux: skip the OS matrix — it doubles cost for platforms you never ship. Cross-compilation is cheaper than emulation: GOOS=windows go build ./... catches most portability breaks.

4. Coverage Gate

yaml
- run: go test -race -coverprofile=coverage.out ./...
- name: enforce coverage floor
  run: |
    total=$(go tool cover -func=coverage.out | awk '/^total:/ {sub(/%/,"",$3); print $3}')
    echo "coverage: ${total}%"
    awk -v t="$total" 'BEGIN { exit (t < 70.0) }'

Gate on a floor that ratchets up, not a target that gets gamed. Exclude generated code via //go:generated files' build tags or grep filters, not by lowering the floor.

5. Makefile — Local Mirror of CI

CI must run what developers run. One definition, two callers:

makefile
.PHONY: build lint test vuln ci

build:
	go build ./...

lint:
	golangci-lint run

test:
	go test -race -shuffle=on -coverprofile=coverage.out ./...

vuln:
	go run golang.org/x/vuln/cmd/govulncheck@latest ./...

ci: build lint test vuln

If CI does anything make ci doesn't, developers discover failures only after pushing. Keep them identical.

6. Speed Rules

  • Split lint / test / vuln into parallel jobs (as in §1).
  • go test ./... already parallelizes across packages; don't shard a

small repo.

  • Integration tests behind a build tag run in a separate job or on a

schedule, not on every push: go test -tags=integration ./....

  • If the build cache misses constantly, check that go.sum is the

cache key input (setup-go does this) and that jobs don't mutate it.

Verification Checklist

  1. Pipeline has all four gates: build, vet+lint, test -race, govulncheck
  2. Go version sourced from go.mod (go-version-file), not duplicated
  3. permissions: contents: read set at workflow level
  4. Tests run with -race -shuffle=on
  5. .golangci.yml committed with a curated linter set
  6. Every nolint carries a linter name and a reason
  7. Matrix limited to versions/platforms actually supported
  8. Coverage floor enforced, generated code excluded
  9. make ci reproduces the pipeline locally, byte-for-byte
  10. Integration tests isolated behind tags, not slowing every push

Related by task

from this repository

More skills

All skills
eduardo-sl
Community

go-cli

Build command-line tools in Go: flag handling, subcommands, stdin/stdout discipline, exit codes, signal handling, and when Cobra/Viper earn their weight over the standard library. Use when: "build a CLI", "add a subcommand", "parse flags", "exit codes", "handle Ctrl+C", "cobra command", "read from stdin", "CLI UX". Not for: HTTP APIs (go-api-design), scaffolding (go-project-layout), service configuration (go-architecture-review).

installs
1
GitHub stars
71
Updated
Aug 18
eduardo-sl
Community

go-coding-standards

Go coding standards and style conventions grounded in Effective Go, Go Code Review Comments, and production-proven idioms. Use when writing or reviewing Go code, enforcing naming conventions, import ordering, variable declarations, struct initialization, or formatting rules. Trigger examples: "check Go style", "fix formatting", "review naming", "Go conventions". Not for: architecture (go-architecture-review), concurrency (go-concurrency-review), performance tuning (go-performance-review).

installs
1
GitHub stars
71
Updated
Aug 18
eduardo-sl
Community

go-context

Correct usage of context.Context in Go: propagation, cancellation, timeouts, deadlines, values, and common anti-patterns. Use when: "context usage", "context.Context", "context cancellation", "timeout", "context.WithTimeout", "context.WithCancel", "context values", "context propagation". Not for: concurrency beyond context (go-concurrency-review), HTTP middleware (go-api-design), error handling (go-error-handling).

installs
1
GitHub stars
71
Updated
Aug 18
eduardo-sl
Community

go-dependency-injection

Dependency injection in Go: constructor injection, wiring in main, avoiding global state, and when frameworks (wire, fx, dig) earn their complexity. Use when: "dependency injection", "wire up dependencies", "inject this", "remove global state", "singleton in Go", "use google/wire", "uber fx", "make this testable". Not for: interface design (go-interface-design), directory structure (go-project-layout), test doubles and mocks (go-test-quality).

installs
1
GitHub stars
71
Updated
Aug 18