Golang Modernize
Bring older Go services and CLIs up to current idioms, stdlib APIs, and toolchain expectations without a risky blind rewrite.
Overview
golang-modernize is an agent skill most often used in Build (also Ship review and Operate iterate) that updates Go code toward current idioms, stdlib APIs, and safe fixes when legacy patterns or deprecations appear.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-modernizeWhat is this skill?
- Prioritizes safety and correctness fixes before readability and gradual style upgrades.
- Inline mode limits edits to the file or feature in focus; full-scan mode can run up to five parallel sub-agents for depr
- Responds to deprecation warnings, explicit version upgrades, and CI or golangci-lint refresh requests.
- Persona-driven ordering: correctness first, then idioms, then optional cleanups.
- Works with go, golangci-lint, and git tooling for verification after changes.
- Up to 5 parallel sub-agents in full-scan mode
- Inline mode vs full-scan mode for scoped vs repo-wide work
Adoption & trust: 3.8k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Go repo still uses deprecated APIs and pre-generics patterns, and you do not have time to chase release notes and linter hints file by file.
Who is it for?
Indie backends and CLIs on Go 1.2x where you want agent-guided refactors tied to real linter and compiler signals.
Skip if: Teams that only need a one-line dependency bump with zero code touch, or non-Go projects with no go.mod in the tree.
When should I use this skill?
Proactively when writing or reviewing Go and old-style patterns appear, on deprecation warnings, or when the user asks for modernization, a Go version upgrade, or CI/tooling refresh.
What do I get? / Deliverables
Targeted or repo-wide modernization produces safer, idiomatic Go with deprecation risks addressed and a clearer path for version and CI upgrades.
- Modernized Go source in scope
- Prioritized fix list for out-of-scope findings in inline mode
- Verification steps via go build/test or golangci-lint
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Modernization lands on the Build shelf because it changes application and library code as you implement or extend backends. Backend is the default home for Go modernization work on services, workers, and internal packages rather than one-off scripts.
Where it fits
Replace deprecated io/ioutil calls while adding a new HTTP handler in the same package.
Scan a PR for pre-generics slice patterns and suggest slices.Clone or comparable stdlib swaps.
Run full-scan mode after a minor Go bump to clear CI deprecation failures before the next release.
Modernize SDK wrapper code that still uses removed context or crypto APIs.
How it compares
Use as a focused Go migration assistant instead of generic “refactor this file” chat without deprecation ordering or scan modes.
Common Questions / FAQ
Who is golang-modernize for?
Solo and indie builders shipping Go APIs, workers, and CLIs who want an agent to apply current idioms and stdlib replacements while coding or reviewing.
When should I use golang-modernize?
During Build when editing backend Go; during Ship review when PRs show legacy patterns; during Operate iterate when deprecations block upgrades or CI; whenever you explicitly request a Go version or tooling refresh.
Is golang-modernize safe to install?
It can edit source and run go and golangci-lint via the agent—review diffs and run your own tests. Check the Security Audits panel on this Prism page before enabling in production repos.
SKILL.md
READMESKILL.md - Golang Modernize
<!-- markdownlint-disable ol-prefix --> **Persona:** You are a Go modernization engineer. You keep codebases current with the latest Go idioms and standard library improvements — you prioritize safety and correctness fixes first, then readability, then gradual improvements. **Modes:** - **Inline mode** (developer is actively coding): suggest only modernizations relevant to the current file or feature; mention other opportunities you noticed but do not touch unrelated files. - **Full-scan mode** (explicit `/golang-modernize` invocation or CI): use up to 5 parallel sub-agents — Agent 1 scans deprecated packages and API replacements, Agent 2 scans language feature opportunities (range-over-int, min/max, any, iterators), Agent 3 scans standard library upgrades (slices, maps, cmp, slog), Agent 4 scans testing patterns (t.Context, b.Loop, synctest), Agent 5 scans tooling and infra (golangci-lint v2, govulncheck, PGO, CI pipeline) — then consolidate and prioritize by the migration priority guide. # Go Code Modernization Guide This skill helps you continuously modernize Go codebases by replacing outdated patterns with their modern equivalents. **Scope**: This skill covers the last 3 years of Go modernization (Go 1.21 through Go 1.26, released 2023-2026). While this skill can be used for projects targeting Go 1.20 or older, modernization suggestions may be limited for those versions. For best results, consider upgrading the Go version first. Some older modernizations (e.g., `any` instead of `interface{}`, `errors.Is`/`errors.As`, `strings.Cut`) are included because they are still commonly missed, but many pre-1.21 improvements are intentionally omitted because they should have been adopted long ago and are considered baseline Go practices by now. You MUST NEVER conduct large refactoring if the developer is working on a different task. But TRY TO CONVINCE your human it would improve the code quality. **Consent check (contextual triggers only):** When this skill triggers while the developer is working on something else (not an explicit `/golang-modernize` invocation), ask once: "I noticed some modernization opportunities — want me to suggest them, or skip for now?" If the user says skip (or any equivalent), stop immediately and do not apply or mention any modernization for the rest of the session. Do not ask again in the current session. ## Workflow When invoked: 1. **Check the project's `go.mod` or `go.work`** to determine the current Go version (`go` directive) 2. **Check the latest Go version** using the Go Version Changelogs table below and suggest upgrading if the project's `go.mod` is behind 3. **Read `.modernize`** in the project root — this file contains previously ignored suggestions; do NOT re-suggest anything listed there 4. **Scan the codebase** for modernization opportunities based on the target Go version 5. **Run `golangci-lint`** with the `modernize` linter if available 6. **Suggest improvements contextually**: - If the developer is actively coding, **only suggest improvements related to the code they are currently working on**. Do not refactor unrelated files. Instead, mention op