Release Skills
Explore 7 curated release skills for building with AI coding agents — what each one does, when to use it, and how to add it to your workflow.
Canary Release Planner
Design a canary / progressive rollout so a bad release reaches 1% of users instead of 100% — staged traffic with bake times, gating metrics compared against the concurrently-running stable baseline, and automated promote-or-rollback. Use when shipping a risky change, when you want automatic rollback on regression, or when moving off all-at-once deploys.
Changelog From PRs
Draft a release changelog by summarizing merged pull requests since the last tag. Use when preparing a release or writing release notes.
Release Notes Writer
Write user-facing release notes — the curated 'what's new and what it means for you' — by starting from the real changes (git log / merged PRs / the changelog since the last release) and translating developer-speak into user impact, grouped by what the user cares about with breaking changes and required actions surfaced first. Use when shipping a release to users or customers and the raw commit log isn't something a user should read, when you need a published GitHub-release / blog / in-app announcement, or when a breaking change must be made unmissable so upgrades don't break.
Release Readiness Reviewer
Review whether a specific release is ready to ship by checking scope, tests, compatibility, migrations, configuration, observability, rollout, rollback, support, security, and ownership against explicit evidence. Use before a production deployment, major version, risky feature launch, migration, or go/no-go meeting.
Rollback Plan Writer
Write a tested rollback and forward-recovery plan for a release, including triggers, commands, compatibility constraints, data handling, verification, ownership, and stop conditions. Use before high-risk deploys, schema or configuration changes, dependency upgrades, model or provider migrations, feature launches, and any release where 'just redeploy the old version' is incomplete or unsafe.
SemVer Advisor
Decide the correct semantic-version bump — major, minor, or patch — by diffing a release range, mapping the changes onto the public API surface, and classifying each as breaking, additive, or a fix. Use before cutting a release when you are unsure whether changes are breaking, when a teammate proposes a bump you want to sanity-check, or when a behavior change has no signature change and you need to know if it is still breaking.
Version Bumper
Bump the project version everywhere it lives in one consistent pass — package.json, lockfile, nested/CLI package manifests, version constants, README badges, docs — then roll the changelog's Unreleased section under the new version and stage an annotated git tag. Use when you've already decided the new version (X.Y.Z or a pre-release like -rc.1) and need every artifact updated to the same value without drift, or before cutting a release.