# Go Skill Generate

> Generate missing version-specific Go skills from official machine-readable Go release notes and register them with the Go dispatcher. Use when a stable Go major release needs a new go-1-N skill or when refreshing this repository after a Go release.

- Skill: `cedws/go-skill-generate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cedws/go-skill-generate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cedws/go-skill-generate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cedws (https://skillmd.com/u/cedws)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cedws/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:

```text
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:

```yaml
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.