The CLI selects advice from the module's Go version
Modern Go Guidelines gives coding agents a table of language and standard-library features, filtered by the version a project can compile. The examples range from slices.Contains to Go 1.26 additions such as errors.AsType[T]. Its wrapper asks the CLI for a list before an agent edits a Go file, and the agent can request an explanation for a specific rule. That is a narrower job than formatting, linting, or rewriting an existing codebase.
The repository distributes the same core skill through Junie, Claude Code, Codex, Cursor, and skills.sh. Each marketplace has its own install and refresh commands. The wrapper puts its CLI in a local cache and does not modify the target repository during installation. A Go toolchain must be available on PATH, and the CLI targets Go 1.25 or later. Older installations rely on GOTOOLCHAIN=auto to obtain a compatible compiler on first use.
Version filtering is useful, but one reported path chooses the wrong version
The best part is the file-aware lookup. Given a Go source path, the tool reads the surrounding module information and returns only advice allowed by that version. This matters because an agent that suggests min to a Go 1.20 module has produced code the module cannot compile. The skill also tells the agent to read the full list and to request details before skipping a relevant rule.
Issue 14 reports two holes in that promise. A go.mod without a go directive is treated like the local toolchain, although the Go command assigns that module language version 1.16. The report shows the CLI recommending new(30), which then fails because the module language is too old. It also says bare list does not inspect the current directory's go.mod; passing --file-path does. The documented workflow prefers a file path, but the first case can still produce broken code.
What happened when we ran it
Our sandbox installed 3 packages in 16 seconds, built the project in 11 seconds, and passed 6 of 6 tests in 5 seconds. We used commit 40781f1 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image. Nothing in the install, build, or test logs failed.
The checkout was only 0.1 MB, with 29 files and about 1,278 lines of source. Our scan found no GitHub Actions workflow, Dockerfile, or tests directory. The lack of a tests directory does not mean there were no tests: go test discovered 6 tests in the package layout and all passed. The missing CI files mean the repository does not show an in-repo automation path for repeating that result on proposed changes.
Six passing tests do not cover the disputed examples
A green local run is reassuring for the CLI mechanics, but open issue 14 is directly relevant to what the tool teaches. It documents six before-and-after examples whose results differ in specific cases. One swaps outputs when strings.CutLast sees no separator. Another removes a context cleanup by deferring the stop function. Others change nil-map write behavior, NaN handling, or the distinction between nil and an empty slice.
Pull request 20 proposes fixes for those 6 examples, while the issue says its wrong since_version and Go-version detection parts remain outside that change. Pull request 13 separately corrects a new example and adds behavior caveats to summaries that agents see. These are not abstract style disagreements. They show why agent instructions need the same review standard as source code: a concise modernization can compile and still change a program's result.
This complements analyzers instead of replacing them
The tool helps most while an agent is writing new code. For an existing package, deterministic analyzers deserve the first pass because their findings can be repeated without asking a model to interpret prose. Issue 9 makes this point for the modern go fix flow introduced with Go 1.26, asking the skill to run it before model-led modernization. That proposal is still an issue, not documented behavior in the current README.
A sensible workflow uses the guidelines to reduce stale code at generation time, then runs gofmt, analyzers, the compiler, and project tests. The instruction set cannot know whether a zero value is meaningful to your business logic or whether a nil slice must remain nil for JSON output. The project's own disputed examples make those boundaries unusually concrete.
August defect activity is healthier than the missing release history
GitHub showed 1,863 stars, 6 open issues and pull requests combined, and a last push on August 19, 2026. Several defect reports and proposed fixes were active on August 26. That is current issue activity even though the repository API returned no latest release. A missing release tag limits fixed-version adoption and change notes; it does not by itself make the project abandoned.
Modern Go Guidelines is worth installing for a team that already reviews agent output and wants fewer stale idioms. Our 32 seconds of install, build, and test time makes evaluation easy. Keep its authority bounded: let it suggest version-appropriate syntax, but require normal Go checks and a semantic review before accepting the result.