releasekit

Derives semver versions and changelogs from Conventional Commits, then tags and publishes GitHub releases.

1|Updated Jul 12, 2026
One-click install
npx skills add https://github.com/mimukit/skills --skill releasekit-mimukit
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: releasekit
Source: https://github.com/mimukit/skills/tree/main/skills/releasekit
Command: npx skills add https://github.com/mimukit/skills --skill releasekit-mimukit

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning merged work into a release means manually deciding the next version number, writing a changelog, bumping manifest files, tagging, and creating a GitHub release. This Skill automates that entire sequence from the Conventional Commits already in the git log, with a mandatory preview before anything mutates. ## Core Features & Use Cases - Automatic version derivation: Parses the commit range since the last release tag and computes the correct semver bump, including special 0.x rules and breaking-change detection from commit bodies. - Changelog generation: Renders a Keep a Changelog section grouped into Added, Changed, Fixed, Removed, and Other, reused verbatim for the GitHub release body. - Two release paths: Pushes directly on unprotected branches, or opens a release PR on protected branches and finishes the tag after merge. - Use Case: After merging several feature PRs into main, ask for a release and get a preview showing v1.4.0 derived from three feat commits, the full changelog, and the exact commands about to run, then confirm to tag and publish. ## Quick Start Ask the agent to cut a release from the current branch, for example by saying "cut a release and show me the next version and changelog before tagging".

Frequently Asked Questions about releasekit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a changelog from Conventional Commits?

Parse the commit range since the last semver tag and group subjects by type into Keep a Changelog sections: feat becomes Added, fix becomes Fixed, and breaking changes get their own section. This Skill renders that section once and reuses it for both CHANGELOG.md and the GitHub release body.

How do I determine the next semver version from git history?

Read the commits since the nearest semver ancestor tag and take the highest applicable bump: breaking changes bump major, feat bumps minor, and fix or perf bumps patch. On 0.x versions, breaking changes bump minor and feat bumps patch instead, following the release-please and Cargo convention.

Does this work with protected branches on GitHub?

Yes, it probes branch protection via the GitHub API and switches to a release-PR path when the base branch is protected. It opens a release branch and PR with the version bump and changelog, then tags the merged commit on a second run.

Can I use this with semantic-release or changesets?

No, it refuses to run when it detects competing release tooling such as .changeset/, .releaserc, release-please config, or a semantic-release dependency. Those tools own versioning end to end, and a second writer would corrupt their state.

Does it publish packages to npm or other registries?

No, it stops at creating the annotated git tag and GitHub release. Registry publishing is left to CI workflows triggered by the tag, keeping credentials and irreversible uploads out of the interactive release step.

Why does the release fail when CI checks are failing?

It reads the check rollup for the base branch head commit and refuses to tag a failing one, because a tag on red code spends a version number on unusable code. The --allow-red flag overrides this for a known-flaky required check.