goreleaser
Skill2 starsChanged 7 months agoMITView on GitHub
Configure and use GoReleaser for release automation with `.goreleaser.yaml`, `goreleaser build`, and `goreleaser release`. Use this skill when creating or editing GoReleaser config, setting up GitHub Actions release pipelines, building cross-platform binaries, publishing to Homebrew, Scoop, AUR, nFPM, Docker, or other package targets, generating changelogs, or automating release artifacts for Go, Rust, Zig, TypeScript, or Python projects.
- Reads credentials
In this repository26 other files it gives its agents.
- other/AGENTS.mdAGENTS.md
- beamng-modsSkill
- bootstrap-vueSkill
- charmbraceletSkill
- depsdotdevSkill
- find-domainSkill
- github-cliSkill
- go-cobraSkill
- go-viperSkill
- kasettoSkill
- laravel-actionsSkill
- lefthookSkill
- miseSkill
- pelican-panel-pluginsSkill
- php-monorepo-builderSkill
- php-saloonSkill
- prd-todo-slicerSkill
- prd-to-kandev-tasksSkill
- qodo-mergeSkill
- release-pleaseSkill
- rewrite-in-goSkill
- shieldsioSkill
- skill-researcherSkill
- skill-scoutSkill
- taskfileSkill
- website-visual-testingSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 209
When a project uses both release-please and GoReleaser, always implement them in a unified workflow (same workflow file) instead of …
- Very specific: line 211
Use ../release-please/references/release-please-goreleaser-unified-workflow.md as the canonical integration recipe.
- Very specific: line 214
Use its outputs (release_created, tag_name) to conditionally run GoReleaser.
- Very specific: line 216
Use GITHUB_TOKEN and avoid introducing a custom PAT just to trigger GoReleaser.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GoReleaser Skill
GoReleaser automates the release process for software projects. It builds binaries, creates archives, publishes to package managers, builds Docker images, and generates changelogs.
Quick Reference
| Task | Reference File |
| Build configuration | references/builds.md |
| Archives (tar.gz, zip) | references/archives.md |
| Docker images | references/docker.md |
| Linux packages (deb/rpm) | references/nfpm.md |
| Homebrew/Scoop/AUR | references/homebrew.md |
| Signing & notarization | references/signing.md |
| Changelog generation | references/changelog.md |
| CI/CD integration | references/ci.md |
| release-please integration | ../release-please/references/release-please-goreleaser-unified-workflow.md |
| Template variables | references/templates.md |
| Complete examples | references/examples.md |
Essential Commands
# Initialize new config
goreleaser init
# Validate configuration
goreleaser check
# Test build locally (no publish)
goreleaser release --snapshot --clean
# Create release (usually run in CI)
goreleaser releaseConfiguration File
GoReleaser uses .goreleaser.yaml (or .goreleaser.yml). Enable schema validation:
# yaml-language-server: $schema=https://goreleaser.com/static/schema.json
version: 2
# Project name (defaults to directory name)
project_name: myappMinimal Go Configuration
# yaml-language-server: $schema=https://goreleaser.com/static/schema.json
version: 2
builds:
- main: ./cmd/myapp
binary: myapp
goos: [linux, darwin, windows]
goarch: [amd64, arm64]
ldflags:
- -s -w
- -X main.version={{.Version}}
archives:
- formats: [tar.gz]
format_overrides:
- goos: windows
formats: [zip]
changelog:
sort: asc
filters:
exclude:
- "^docs:"
- "^test:"Build Targets
Go (default)
builds:
- builder: go # optional, default
main: ./cmd/app
goos: [linux, darwin, windows]
goarch: [amd64, arm64]
goarm: ["6", "7"] # for ARM buildsRust
builds:
- builder: rust
targets:
- x86_64-unknown-linux-gnu
- x86_64-apple-darwin
- aarch64-apple-darwinZig
builds:
- builder: zig
targets:
- x86_64-linux-gnu
- x86_64-macos
- aarch64-macosPrebuilt Binaries
builds:
- builder: prebuilt
prebuilt:
path: dist/myapp_{{ .Os }}_{{ .Arch }}/myapp{{ .Ext }}Common Patterns
Version Injection (Go)
builds:
- ldflags:
- -X main.version={{.Version}}
- -X main.commit={{.Commit}}
- -X main.date={{.Date}}CGO Disabled
builds:
- env:
- CGO_ENABLED=0Multiple Binaries
builds:
- id: cli
main: ./cmd/cli
binary: myapp
- id: server
main: ./cmd/server
binary: myapp-serverPublishing
Homebrew Tap
brews:
- repository:
owner: myorg
name: homebrew-tap
homepage: https://example.com
description: "My application"Docker Images
dockers_v2:
- dockerfile: Dockerfile
images:
- "ghcr.io/myorg/myapp:{{ .Tag }}"
- "ghcr.io/myorg/myapp:latest"GitHub Release
release:
github:
owner: myorg
name: myrepo
draft: false
prerelease: autoEnvironment Variables
| Variable | Purpose |
GITHUB_TOKEN | GitHub API access |
GITLAB_TOKEN | GitLab API access |
GITEA_TOKEN | Gitea API access |
GORELEASER_KEY | Pro license key |
Workflow
- Initialize:
goreleaser initcreates.goreleaser.yaml - Configure: Edit config for your needs (see reference files)
- Validate:
goreleaser checkverifies configuration - Test:
goreleaser release --snapshot --cleantests locally - Release: Tag and push, CI runs
goreleaser release
release-please Integration Rule
When a project uses both release-please and GoReleaser, always implement them in a unified workflow (same workflow file) instead of separate chained workflows.
Use ../release-please/references/release-please-goreleaser-unified-workflow.md as the canonical integration recipe.
- Run
googleapis/release-please-action@v4first. - Use its outputs (
release_created,tag_name) to conditionally run GoReleaser. - Checkout
ref: ${{ needs.release-please.outputs.tag_name }}beforegoreleaser release --clean. - Use
GITHUB_TOKENand avoid introducing a custom PAT just to trigger GoReleaser.
This avoids GitHub Actions token recursion issues and removes the need for release-trigger PAT workarounds.
When to Load References
- Setting up builds: Load
references/builds.mdfor complete build options - Configuring Docker: Load
references/docker.mdfor multi-arch images - Linux packages: Load
references/nfpm.mdfor deb/rpm/apk packages - Package managers: Load
references/homebrew.mdfor Homebrew/Scoop/AUR/etc. - CI setup: Load
references/ci.mdfor GitHub Actions/GitLab CI - release-please integration: Load
../release-please/references/release-please-goreleaser-unified-workflow.mdfor the unified no-custom-PAT workflow - Template syntax: Load
references/templates.mdfor available variables - Complete examples: Load
references/examples.mdfor copy-paste configs
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
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.

