Go Skill Generate

Generate Go release skills

Discover releases

1. Locate the sibling go skill and read its release table.
2. Fetch https://go.dev/dl/?mode=json&include=all as JSON.
3. Consider only stable initial major releases at Go 1.26 or later whose version matches go1.N or go1.N.0. Exclude betas, release candidates, and patch releases.
4. Normalise the version to 1.N.
5. Fetch https://go.dev/doc/devel/release as structured HTML and read the exact ISO date from the matching major-release heading.
6. Sort candidates by numeric minor version.
7. Check for ../go-1-N/SKILL.md before retrieving or generating anything. Skip every version whose skill already exists. Never replace, merge, or regenerate an existing version skill.

Require the download JSON and release history to agree that the version is stable. Do not infer a release or date from a schedule, beta, release candidate, branch, draft note, file timestamp, or current date.

Retrieve machine-readable release notes

For each missing stable version, fetch the official Markdown source from:

https://go.googlesource.com/website/+/master/_content/doc/go1.N.md?format=TEXT

Decode the Gitiles response from base64 to UTF-8 Markdown. Require its title and introduction to match Go 1.N and reject notes still marked as draft. If the Markdown source is unavailable, use the structured HTML at https://go.dev/doc/go1.N; do not use search snippets, third-party summaries, blog commentary, or model memory as substitutes for the complete release notes.

Select useful changes

Extract changes that affect how developers should write, modernise, test, build, or operate Go programs:

• language and type-system features;
• new commands, command behaviour, analysers, modernisers, and module semantics;
• new standard-library packages, exported APIs, and materially changed behaviour;
• deprecations and clear replacements for older patterns;
• runtime or platform changes that affect application design, compatibility, observability, or deployment;
• experimental features, clearly labelled with their opt-in mechanism and stability limits.

Leave out patch-release material, ordinary bug fixes, internal compiler or linker details with no developer action, exhaustive platform minutiae, performance claims that do not change a decision, and long lists of minor constants.

Write the skill

Create only ../go-1-N/SKILL.md with name and description frontmatter.

Normalise every generated description to this exact template, replacing 1.N and YYYY-MM-DD with the discovered version and release date:

description: Apply Go 1.N language features, tooling, standard-library APIs, migrations, and behaviour changes. Load for Go work targeting 1.N or later when the model's knowledge may predate the YYYY-MM-DD release.

Keep the description on one physical line. Do not add feature names, URLs, Markdown, release-note wording, or extra trigger fields to it.

Write the body as a concise factual overview of the release's developer-facing changes:

1. State that the overview applies to target Go versions of at least 1.N.
2. Explain what each important feature or API does and the situations it supports without directing the agent to adopt it.
3. Pair deprecated or superseded patterns with their modern replacement and explain the difference factually.
4. Cover language, tools, standard library, testing, compatibility, and experimental features only when the release notes contain relevant material.
5. Include compact Go examples only when they clarify correct usage.
6. Do not invent recommendations, APIs, guarantees, or migration rules not supported by the release notes.
7. Keep advice from earlier Go versions out of the skill unless it is necessary to explain what this release replaces.
8. Keep the skill concise enough to load alongside other release skills.

Use descriptive, non-imperative wording in the generated body. Prefer forms such as “clear can empty a map” or “slices.Concat concatenates slices”. Avoid directive openings such as “Use”, “Do”, “Prefer”, “Replace”, “Run”, “Enable”, or “Require”.

Register and validate

After writing a new skill:

1. Validate that the directory name and frontmatter name are both go-1-N.
2. Add one row to the sibling go skill's release table with version, ISO release date, and skill name.
3. Keep the table sorted in ascending numeric version order.
4. Report skipped existing skills separately from newly generated skills.

If generation or validation fails for one version, do not register that version and continue with later independent candidates.