Cut release branches, apply annotated version tags, and ship build artifacts to registries.
npx skills add https://github.com/kieranpotts/skills --skill release-kieranpotts
Please help me install this Agent Skill. Skill: release Source: https://github.com/kieranpotts/skills/tree/main/skills/release Command: npx skills add https://github.com/kieranpotts/skills --skill release-kieranpotts
release/<version> branches, and cuts or advances the branch from the release-ready trunk. - Changelog promotion and tagging: Promotes the changelog's unreleased section to the released version and date, then applies an annotated version tag following the project's tagging convention. - Artifact shipping and release notes: Builds and publishes artifacts to the project's registry (Docker, npm, PyPI, S3) and drafts user-facing release notes filtered of internal changes. - Use Case: After merging the final feature for version 1.2.0, invoke the Skill to cut release/1.2.0 from the ready trunk, promote the changelog, tag v1.2.0, and push the build to the registry — all without touching source code. ## Quick Start Ask the agent to cut a release for the current project, for example by saying "tag version 1.2.0 and ship the release".High-intent search queries and answers about installing and using this skill.
Create the release branch from the release-ready trunk with git checkout -b release/<version>, then apply an annotated tag using git tag -a v<version> -m "<notes>". Annotated tags record the tagger, date, and message needed for release provenance.
A release trunk is a single permanent branch fast-forwarded for each release, suiting continuous deployment. Temporary release/<version> branches suit release trains and are deleted after tagging and deployment succeed. A project must use exactly one model, never both.
No, the changelog is optional. The Skill resolves the changelog store from project context or convention files and skips promotion if none exists. It never assumes a CHANGELOG.md at the repository root.
No, fixes must never be committed to a release branch. Fixes flow back through the integration trunk and out to the release-ready trunk, so a fix made under release pressure is never stranded off the mainline.
The branch can be cut as release/next and renamed once the version is settled. No version tag is applied until the version is known, since version tags are treated as permanent.
contentbugvideoeditingDefine branching strategies, commit conventions, and release tagging for Git workflows.
mkrlabsAutomate GitHub releases with tag validation and build checks.
adriannoesParse repository tags and commit history to generate markdown changelog entries.
sapatamuku-creatorStructures git commits, branching, semantic versioning, and changelog practices for code changes.