Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Dependency management strategies for Golang projects — go.mod management, installing/upgrading packages, Minimal Version Selection, vulnerability scanning, outdated dependency tracking, binary size analysis, Dependabot/Renovate setup, conflict resolution, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, auditing vulnerabilities, resolving version conflicts, or setting up automated dependency updates.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 202% | 0% |
| case-19 | ✗→✓ | ▲ Improved | 149% | 0% |
| case-02 | ✓→✓ | = Same ✓ | 146% | 0% |
| case-03 | ✓→✓ | = Same ✓ | 64% | 0% |
| case-04 | ✓→✓ | = Same ✓ | 51% | 0% |
Persona: You are a Go dependency steward. You treat every new dependency as a long-term maintenance commitment — you ask whether the standard library already solves the problem before reaching for an external package.
Dependencies:
go install golang.org/x/vuln/cmd/govulncheck@latestBefore running go get to add any new dependency, AI agents MUST ask the user for confirmation. AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using go get -u to upgrade an existing dependency is safe.
Before proposing a dependency, evaluate:
The samber/cc-skills-golang@golang-popular-libraries skill contains a curated list of vetted, production-ready libraries. Prefer recommending packages from that list. When no vetted option exists, favor well-known packages from the Go team (golang.org/x/...) or established organizations over obscure alternatives.
go.sum MUST be committed — it records cryptographic checksums of every dependency version, letting go mod verify detect supply-chain tampering. Without it, a compromised proxy could silently substitute malicious codegovulncheck ./... or go tool govulncheck ./... before every release — catches known CVEs in your dependency tree before they reach productiongo mod tidy before every commit that changes dependencies — removes unused modules and adds missing ones, keeping go.mod honest| Command | Purpose | | ----------------- | -------------------------------------------- | | go mod tidy | Add missing deps, remove unused ones | | go mod download | Download modules to local cache | | go mod verify | Verify cached modules match go.sum checksums | | go mod vendor | Copy deps into vendor/ directory | | go mod edit | Edit go.mod programmatically (scripts, CI) | | go mod graph | Print the module requirement graph | | go mod why | Explain why a module or package is needed |
Use go mod vendor when you need hermetic builds (no network access), reproducibility guarantees beyond checksums, or when deploying to environments without module proxy access. CI pipelines and Docker builds sometimes benefit from vendoring. Run go mod vendor after any dependency change and commit the vendor/ directory.
bashgo get github.com/google/uuid # Latest version go get github.com/google/uuid@v1.6.0 # Specific version go get github.com/google/uuid@latest # Explicitly latest go get github.com/google/uuid@<commit> # Specific commit (pseudo-version)
Before pinning a version, inspect the module's available versions, importers, and known vulnerabilities on pkg.go.dev → See samber/cc-skills-golang@golang-pkg-go-dev skill.
bashgo get -u ./... # Upgrade ALL direct+indirect deps to latest minor/patch go get -u=patch ./... # Upgrade to latest patch only (safer) go get github.com/pkg@v1.5 # Upgrade specific package
Prefer go get -u=patch for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:
bashgo get -u=patch ./... go mod tidy go test ./... go vet ./... govulncheck ./... # or: go tool govulncheck ./...
Release notes and changelogs for libraries affecting persistence, serialization, networking, authentication, authorization, cryptography, or public APIs may contain important information about breaking changes.
bashgo get github.com/google/uuid@none # Mark for removal go mod tidy # Clean up go.mod and go.sum
For Go 1.24+ modules, pin executable tools in go.mod with tool directives. Do not create a new tools.go blank-import file unless the module must support Go <1.24.
bash# Add tools to the current module. go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest go get -tool golang.org/x/vuln/cmd/govulncheck@latest go get -tool golang.org/x/perf/cmd/benchstat@latest # Run pinned tools reproducibly. go tool golangci-lint run ./... go tool govulncheck ./... go tool benchstat old.txt new.txt # Install all module-pinned tools into GOBIN/PATH when needed. go install tool # Update pinned tools deliberately, then review go.mod/go.sum. go get -u tool go mod tidy
go.mod shape for a module targeting Go 1.26 or newer. This is an example target, not a cap; keep the project's actual go directive and do not change it just to add tools.
go.modmodule example.com/project go 1.26 tool ( github.com/golangci/golangci-lint/v2/cmd/golangci-lint golang.org/x/vuln/cmd/govulncheck golang.org/x/perf/cmd/benchstat )
For Go <1.24 only, use the legacy tools.go blank-import workaround:
go//go:build tools package tools import ( _ "github.com/golangci/golangci-lint/v2/cmd/golangci-lint" _ "golang.org/x/vuln/cmd/govulncheck" )
Rule: Go 1.24+ = tool directives. Go <1.24 = tools.go fallback.
When using a Go 1.26 or newer toolchain, go mod init may create a module with an older default go directive. If the project intentionally targets Go 1.26+ APIs, update the directive deliberately:
bashgo mod edit -go=1.26 go mod tidy
For future Go versions, use the project's intended target version. Do not use APIs newer than the module's go directive until the project explicitly agrees to upgrade it.
govulncheck, tracking outdated dependencies, analyzing which dependencies make the binary large (goweight), and distinguishing test-only vs binary dependencies to keep go.mod clean.go get does when you request incompatible versions), resolution strategies (replace directives for local development, exclude for broken versions, retract for published versions that should be skipped), and workflows for conflicts across your dependency tree.go.work files for multi-module development (e.g., library + example application), when to use workspaces vs monorepos, and workspace best practices.go mod graph to inspect the full dependency tree, modgraphviz to visualize it, and interactive tools to find which dependency chains cause bloat.samber/cc-skills-golang@golang-continuous-integration skill for Dependabot/Renovate CI setupsamber/cc-skills-golang@golang-security skill for vulnerability scanning with govulnchecksamber/cc-skills-golang@golang-popular-libraries skill for vetted library recommendationsbash# Start a new module go mod init github.com/user/project # Add a dependency go get github.com/google/uuid@v1.6.0 # Upgrade all deps (patch only, safer) go get -u=patch ./... # Remove unused deps go mod tidy # Check for vulnerabilities govulncheck ./... # or: go tool govulncheck ./... # Check for outdated deps go list -u -m -json all | go-mod-outdated -update -direct # Analyze binary size by dependency goweight # Understand why a dep exists go mod why -m github.com/some/module # Visualize dependency graph go mod graph | modgraphviz | dot -Tpng -o deps.png # Verify checksums go mod verify
Other measured skills in the registry, with their headline benchmark lift.