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:

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:

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

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.