Automate project releases by deriving semver from changelogs and triggering GoReleaser workflows.

Install

mkdir -p .claude/skills/release-andrewdryga && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/19274" && unzip -o skill.zip -d .claude/skills/release-andrewdryga && rm skill.zip

Installs to .claude/skills/release-andrewdryga

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Cut a versioned release of coop — derive the semver bump from the `## Unreleased` changelog, finalize + annotated-tag it, then (only on explicit confirmation) push the `v*` tag that triggers the public GoReleaser build. Refuses a docs-only no-op release. Use when asked to "cut / ship / tag a release", "publish a release", or "bump the version".
346 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Advanced

Key capabilities

  • Derive semver bumps from Unreleased changelog entries
  • Finalize changelog sections for new versions
  • Create annotated git tags for release points
  • Regenerate help documentation casts at specific versions
  • Trigger public GoReleaser build pipelines

How it works

It validates the repository state, updates the changelog, tags the commit, and pushes to trigger an automated CI pipeline that builds and signs public artifacts.

Inputs & outputs

You give it
Version number or changelog content
You get back
Public signed GitHub release with binaries

When to use release

  • Ship a new version of the codebase
  • Bump version and tag the repository
  • Automate public binary release generation

About this skill

/release — cut one clean, signed release

Releases are tag-driven: the version comes from git describe --tags, and pushing a v* tag fires .github/workflows/release.yml → GoReleaser builds every OS/arch and publishes a public, cosign-signed GitHub Release (binaries + checksums.txt + build provenance) that install.sh serves. The tag push is the point of no return — everything before it is local and reversible; after it, the artifacts are public. Don't poke at the Makefile/workflow each time — this is the contract; follow it.

1. Pre-flight — is there anything real to ship?

  • On main, clean tree, not behind origin/main (the only ahead commits should be your own release prep). Gate green: make check.
  • Refuse a no-op. git diff --stat "$(git tag --sort=v:refname | tail -1)"..main — if it touches only CHANGELOG.md/docs (no code), STOP: the binary would be byte-identical to the last release. The fix is almost always changelog attribution, not a new version — move the entry under the release where the code actually shipped (git tag --contains <commit> shows which one already has it). Cutting a version for unchanged code misdates the feature.
  • The ## Unreleased entries ARE the release. Empty ⇒ nothing to cut; say so and stop.
  • Optional dry-run: make snapshot (GoReleaser --snapshot --clean --skip=sign, no publish; signing is CI-only keyless OIDC) to catch config breakage before any tag exists.

2. Pick the version (semver — or take the user's)

  • Latest: git tag --sort=v:refname | tail -1.
  • Bump by what's in Unreleased: new functionality → minor x.Y.0; fixes/hardening only → patch x.y.Z; a breaking change → major. A version the user named wins.
  • Guard: the tag must not already exist and must sort after the latest.

3. Finalize + tag (all local, still reversible)

  • Rename ## Unreleased## <version> (NO date — house format is a bare ## X.Y.Z). Keep entries as - **Bold headline.** explanation.
  • Commit CHANGELOG-only: changelog: finalize <version> (<one-line summary>).
  • Annotated tag on THAT finalize commit: git tag -a "v<version>" -m "v<version>" (tags are annotated and point at the finalize commit, never the re-open commit).
  • Re-true the site casts now — with HEAD at the tag, ./coop version is the exact v<version>, so make casts re-captures site/casts/help.cast with the release version, not a dev/dirty one (it rebuilds ./coop and refuses an untagged/+dirty binary). Commit the refreshed casts: casts: regenerate at v<version>.
  • Re-open: add a fresh ## Unreleased + the placeholder comment back; commit changelog: open an Unreleased section after v<version>.

4. Push — public, irreversible: CONFIRM FIRST

  • Show the user the version, the one-line summary, and that this publishes a public signed release. Get an explicit go-ahead — this is the one outward-facing, hard-to-undo step.
  • Then: git push origin main && git push origin "v<version>".
  • Watch it land: gh run watch (or gh run list --workflow=release.yml), then gh release view "v<version>" to confirm the assets + checksums.txt uploaded.

5. If it breaks

  • Failed before publishing? Delete the tag both sides (git tag -d "v<version>", git push origin ":v<version>"), fix, retry.
  • Already published? Never rewrite a public tag — roll forward with a follow-up patch.

When not to use it

  • Cutting a release for documentation-only changes
  • Releasing when the changelog has no Unreleased entries
  • Rewriting public tags after a release

Prerequisites

gitmake

Limitations

  • Refuses to cut a release if only documentation files are changed
  • Requires a clean git tree before execution

How it compares

This workflow enforces a strict contract that prevents byte-identical releases and ensures all artifacts are signed and provenance-tracked.

Compared to similar skills

release side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
release (this skill)018dNo flagsAdvanced
turborepo611moReviewIntermediate
bazel-build-optimization142moNo flagsAdvanced
ml-pipeline-workflow94moNo flagsAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

turborepo

vercel

Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.

61191

bazel-build-optimization

wshobson

Optimize Bazel builds for large-scale monorepos. Use when configuring Bazel, implementing remote execution, or optimizing build performance for enterprise codebases.

14116

ml-pipeline-workflow

wshobson

Build end-to-end MLOps pipelines from data preparation through model training, validation, and production deployment. Use when creating ML pipelines, implementing MLOps practices, or automating model training and deployment workflows.

995

linkerd-patterns

wshobson

Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.

672

deployment-pipeline-design

wshobson

Design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use when architecting deployment workflows, setting up continuous delivery, or implementing GitOps practices.

670

glab

NikiforovAll

Expert guidance for using the GitLab CLI (glab) to manage GitLab issues, merge requests, CI/CD pipelines, repositories, and other GitLab operations from the command line. Use this skill when the user needs to interact with GitLab resources or perform GitLab workflows.

664

Search skills

Search the agent skills registry