agentleFS
agentstationagentstation/skills/use-modern-go/SKILL.md

use-modern-go

Skill1 starsChanged 2 months agoMITView on GitHub

Use this skill for any task that writes, modifies, reviews, fixes, or refactors Go source, tests, module files, or tooling. Invoke it when the user requests a Go feature, bug fix, migration, performance change, code review, test change, dependency update, or cleanup, even if they do not mention Go style. Do not invoke it only to read, explain, or answer questions about existing Go code.

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

30 rules. 0 are common, 21 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 21

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Write Go in one project-selected form.

    line 15
  2. Distinctive:

    Read the nearest AGENTS.md and repository instructions.

    line 20
  3. Distinctive:

    Read the affected source, tests, callers, interfaces, and recent changes.

    line 23
  4. Distinctive:

    Do not use a feature only because the local toolchain accepts it.

    line 26
  5. Very specific:

    Run the bundled modern-guidelines wrapper before you review or edit Go code.

    line 34
  6. Distinctive:

    Use the host's approval flow when the install needs network or write access.

    line 51
  7. Distinctive:

    If no target file exists, pass the known version:

    line 53
  8. Distinctive:

    Read the complete output. Do not filter or truncate it.

    line 59
  9. Very specific:

    If files use different module versions, run list once for each version.

    line 68
  10. Very specific:

    Before a Go code change or review, inspect go.mod for this module tool:

    line 74
  11. Very specific:

    Use go tool goago when the module declares the tool.

    line 80
  12. Very specific:

    Do not install goago or add a policy unless the user requests adoption.

    line 87
  13. Distinctive:

    When the repository owns a goago command, discover the resolved policy before you choose a Go form:

    line 90
  14. Very specific:

    Use each rules[].enabled value as the active restriction set.

    line 97
  15. Very specific:

    If the module still pins github.com/agentstation/ago/cmd/ago, use go tool ago until the user requests migration.

    line 106
  16. Distinctive:

    Use the newest applicable form that the target version and policy accept.

    line 113
  17. Distinctive:

    Keep new code consistent with the selected project policy.

    line 114
  18. Distinctive:

    Prefer the simplest form that keeps control flow, ownership, and data visible.

    line 115
  19. Distinctive:

    Keep the smallest coherent change.

    line 118
  20. Distinctive:

    Prefer the standard library when it provides the required contract.

    line 119
  21. Distinctive:

    Keep ownership with the package or type that owns the domain concept.

    line 120
  22. Distinctive:

    Do not edit generated, vendored, or third-party code directly.

    line 121
  23. Distinctive:

    Add a regression test when an automated test can reproduce a defect.

    line 122
  24. Very specific:

    Run gofmt on each changed handwritten Go file.

    line 130
  25. Distinctive:

    Run the affected package tests.

    line 131
  26. Distinctive:

    Run the repository's complete Go check when the task scope permits it.

    line 132
  27. Distinctive:

    Run race or platform checks when the changed behavior depends on them.

    line 133
  28. Distinctive:

    Run goago when the repository owns an available command.

    line 134
  29. Distinctive:

    Use the same goago command form that supplied the policy:

    line 136
  30. Very specific:

    Read the JSON errors field before you change source after status 2.

    line 144

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Modern Go

Write Go in one project-selected form. Use modern Go only inside the repository's compatibility, behavior, and policy boundaries.

Establish the contract

  1. Read the nearest AGENTS.md and repository instructions.
  2. Locate the applicable go.work and go.mod files.
  3. Record the target Go version for each affected module.
  4. Read the affected source, tests, callers, interfaces, and recent changes.
  5. State the current behavior and the behavior that the task requires.

Do not use a feature only because the local toolchain accepts it. The affected module's declared Go version is the default compatibility boundary.

For a review or diagnosis, inspect and report. Do not edit unless the request includes a change.

Read modern Go guidance

Run the bundled modern-guidelines wrapper before you review or edit Go code. Resolve <skill-directory> to this installed skill's directory.

On Linux or macOS, run:

sh "<skill-directory>/scripts/run-tool.sh" list --file-path path/to/file.go

On Windows PowerShell, run:

& '<skill-directory>\scripts\run-tool.ps1' list --file-path path\to\file.go

The first run installs the pinned Modern Go Guidelines CLI in a user cache. Use the host's approval flow when the install needs network or write access.

If no target file exists, pass the known version:

sh "<skill-directory>/scripts/run-tool.sh" list --go-version 1.24

Read the complete output. Do not filter or truncate it. Older entries can still apply to the target version.

Request details only for a relevant guideline:

sh "<skill-directory>/scripts/run-tool.sh" explain guideline-id

If files use different module versions, run list once for each version. If the command is unavailable, use repository evidence and report the skipped guidance check.

Resolve the goago policy

Before a Go code change or review, inspect go.mod for this module tool:

tool github.com/agentstation/goago/cmd/goago

Use go tool goago when the module declares the tool. Use a global goago command only when repository instructions require it. Read the nearest .goago.yml or .goago.yaml when one exists.

A goago policy file is optional. The pinned goago version supplies built-in defaults when no policy file exists.

Do not install goago or add a policy unless the user requests adoption. If the goago Agent Skill is available, use its complete remediation workflow.

When the repository owns a goago command, discover the resolved policy before you choose a Go form:

go tool goago -list -format json

Use each rules[].enabled value as the active restriction set. Also read policy.ruleSource, policy.configPath, policy.tests, and policy.exclude. A built-in rule source is a complete policy, not a missing policy. A config rule source records the selected policy file.

An active goago restriction takes priority over a modern form. For example, do not use expression-based new when no-new-expr is active. Keep a generic operation as a package function when no-generic-methods is active.

If the module still pins github.com/agentstation/ago/cmd/ago, use go tool ago until the user requests migration. Read legacy .ago.yml and .ago.yaml policies too. The goago skill includes the migration procedure. Versions of ago before v0.2.0 do not include the policy JSON metadata.

Make the change

  • Use the newest applicable form that the target version and policy accept.
  • Keep new code consistent with the selected project policy.
  • Prefer the simplest form that keeps control flow, ownership, and data visible.
  • Preserve behavior, exported APIs, wire formats, and error identity unless the task changes them.
  • Keep the smallest coherent change. Do not modernize unrelated code.
  • Prefer the standard library when it provides the required contract.
  • Keep ownership with the package or type that owns the domain concept.
  • Do not edit generated, vendored, or third-party code directly.
  • Add a regression test when an automated test can reproduce a defect.

Skip a relevant modern guideline only when it would fail to compile, change required behavior, or violate project policy. Read its explain output before you skip it.

Verify the result

  1. Run gofmt on each changed handwritten Go file.
  2. Run the affected package tests.
  3. Run the repository's complete Go check when the task scope permits it.
  4. Run race or platform checks when the changed behavior depends on them.
  5. Run goago when the repository owns an available command.

Use the same goago command form that supplied the policy:

go tool goago -stale-ignores -format json ./...

Status 0 means the run completed without findings. Status 1 means the run found a violation or stale ignore. Status 2 means the run was incomplete. Read the JSON errors field before you change source after status 2.

Fix source when the selected goago policy reports a finding. Do not weaken the policy or add a suppression only to make the check pass.

Report the checks, results, skipped checks, and remaining uncertainty.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.