# Goreleaser Skill Generate

> Generate a GoReleaser dispatcher and missing version-specific skills from official GoReleaser releases and announcements. Use when seeding or refreshing this repository with stable GoReleaser minor releases from the last three years.

- Skill: `cedws/goreleaser-skill-generate` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add cedws/goreleaser-skill-generate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cedws/goreleaser-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/goreleaser-skill-generate

---


# Generate GoReleaser skills

## Discover releases

1. Use WebFetch to retrieve every page of `https://api.github.com/repos/goreleaser/goreleaser/releases?per_page=100` needed to cover the previous three years.
2. Treat the OSS GitHub repository as the release authority. Consider only published, non-draft, non-prerelease releases whose tag matches `vM.N.0` exactly.
3. Exclude patch releases, nightlies, release candidates, beta releases, Pro releases, and moving tags.
4. Use each release's `published_at` date in ISO `YYYY-MM-DD` form and keep candidates published on or after the date exactly three years before today.
5. Sort candidates by numeric major and minor version.
6. Check for `../goreleaser-M-N/SKILL.md` before retrieving detailed notes. Skip existing version skills without replacing, merging, or regenerating them.

Do not infer releases or dates from schedules, branches, draft notes, search snippets, tag timestamps, or model memory.

## Retrieve official notes

For each missing release, use WebFetch to retrieve its complete GitHub release body and the matching official announcement at:

```text
https://goreleaser.com/blog/goreleaser-vM.N/
```

Require the announcement title or release page to identify the same `M.N` version. The GitHub release remains authoritative when an announcement is absent. Do not use third-party summaries, issue commentary, or patch-release notes as substitutes.

## Select useful changes

Extract changes that affect how practitioners configure, migrate, build, package, sign, publish, announce, or verify releases:

- configuration keys, schema changes, templates, hooks, and defaults;
- builders, targets, archives, packages, installers, container images, and SBOMs;
- signing, notarisation, attestations, checksums, and supply-chain behaviour;
- publishers, source-control integrations, changelogs, announcements, and CI;
- CLI commands, flags, environment variables, split-and-merge workflows, and output behaviour;
- deprecations, removals, migration requirements, and clear replacements;
- Pro-only and experimental features, explicitly labelled as such.

Leave out ordinary bug fixes, dependency bumps, project news, event announcements, download instructions, star counts, contributor counts, and internal changes without practitioner impact.

## Create the dispatcher

Create `../goreleaser/SKILL.md` with the skill-creator initialisation script when it does not exist. Its frontmatter must be:

```yaml
---
name: goreleaser
description: Configure, review, migrate, and verify GoReleaser release workflows while loading release-specific guidance newer than the model's knowledge cutoff. Use for .goreleaser.yaml files, GoReleaser CLI commands, packaging, signing, publishing, and release automation.
---
```

Give the dispatcher these responsibilities:

1. Determine the target GoReleaser binary version from an explicit user request, CI or installation pins, or `goreleaser --version`, in that order. Never treat the configuration's top-level `version` field as the binary version.
2. Compare the target and model knowledge cutoff with a release table, then load applicable sibling release skills oldest first.
3. Preserve project conventions, distinguish OSS from Pro features, and consult the version-matched JSON schema when exact configuration fields are uncertain.
4. Run `goreleaser check` for configuration validation and `goreleaser release --snapshot --clean` only when a local snapshot build is safe and useful.
5. Never publish, announce, upload, sign with real credentials, create tags, or otherwise perform a production release unless the user explicitly requests it.

Add `agents/openai.yaml` with display name `GoReleaser`, short description `Build and maintain GoReleaser workflows`, and a one-sentence default prompt that explicitly mentions `$goreleaser`.

## Write each release skill

Create `../goreleaser-M-N/SKILL.md` with the skill-creator initialisation script and no optional resource directories.

Normalise each description to this exact template, replacing the placeholders with the discovered version and release date:

```yaml
description: Apply GoReleaser M.N configuration, CLI, packaging, migration, and behaviour changes. Load for GoReleaser work targeting M.N or later when the model's knowledge may predate the YYYY-MM-DD release.
```

Write a concise factual body that:

1. States that the overview applies to target GoReleaser versions of at least `M.N`.
2. Explains developer-facing capabilities and their relevant situations without prescribing universal adoption.
3. Pairs deprecated or removed configuration with its supported replacement.
4. Labels Pro-only and experimental features at the point they are mentioned.
5. Includes compact YAML or command examples only when needed to clarify syntax.
6. Excludes advice from earlier versions unless needed to explain a migration.
7. Contains no claims absent from the official release body or announcement.
8. Remains concise enough to load cumulatively with later release skills.

Use descriptive, non-imperative wording in release bodies. Avoid directive openings such as “Use”, “Do”, “Prefer”, “Replace”, “Run”, “Enable”, or “Require”.

Add `agents/openai.yaml` with display name `GoReleaser M.N`, short description `Apply GoReleaser M.N release guidance`, and a one-sentence default prompt that explicitly mentions `$goreleaser-M-N`.

## Register and validate

1. Add a dispatcher table row containing version `M.N`, the ISO release date, and skill `goreleaser-M-N` for every generated skill.
2. Preserve rows for existing skills and sort the table by numeric major and minor version.
3. Validate every created skill and the dispatcher with the skill-creator `quick_validate.py` script.
4. Confirm that every directory name matches its frontmatter name and every `agents/openai.yaml` default prompt names the corresponding skill.
5. Report existing skipped skills separately from newly generated skills.

If one release fails retrieval, generation, or validation, do not register it; continue with later independent candidates.