How do I install the Prepare Release skill?

Run npx skillmds@latest add cliutils/prepare-release in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Prepare Release safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Prepare Release?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Prepare Release free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Prepare Release?

cliutils (@cliutils) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Prepare Release by cliutils — Agent Skill

Name: Prepare Release
Author: cliutils

File contents

Prepare a CLI11 release

When preparing a release (chore: prepare X.Y.Z release):

Collect the changes

List the merged PRs since the last release with git log --oneline --first-parent v<last>..main. Every user-visible change gets a changelog line.

Changelog entry

Add a ## Version X.Y.Z: <Short title> section at the top of CHANGELOG.md. The heading becomes the name of the GitHub release, so give it a short title, such as ## Version 2.7.0: Audit and documentation.

Start with a short prose paragraph that summarizes the release.
Group the entries under ### Added, ### Changed, ### Fixed, ### Documentation, and ### Internal (and ### Removed/### Deprecated if needed). Documentation covers docs-only changes; Internal covers CI, tests, and tooling changes with no user-visible effect.
Reference PRs as [#1305][] and put the matching link definitions ([#1305]: https://github.com/CLIUtils/CLI11/pull/1305) at the end of the version section — each section keeps its own definitions so an extracted section needs no fixup.

Version bump

Bump include/CLI/Version.hpp: the CLI11_VERSION_MAJOR/MINOR/PATCH macros and the CLI11_VERSION string.

Other files

Only if not a patch release: Update the feature markers in README.md: remove the old 🆕 markers (the previous release's features) and change 🚧 markers (main-only features) to 🆕. Removing an emoji from a heading also changes its TOC anchor — drop the trailing - from the matching TOC links.
Check the copyright year in LICENSE and the version in book/chapters/installation.md.

Verify

CI extracts the release notes from the changelog on every build, so a version bump without a matching changelog section fails. Check locally:

python3 scripts/ExtractReleaseNotes.py --title "$(python3 scripts/ExtractVersion.py)"
python3 scripts/ExtractReleaseNotes.py "$(python3 scripts/ExtractVersion.py)"

After the PR merges

Tell the user to tag the merge commit as vX.Y.Z and push the tag. CI then creates the GitHub release: the name comes from the changelog heading, the body from the changelog section, and the single header plus source packages are attached automatically.

---name: prepare-releasedescription: Prepare a CLI11 release — changelog entry, version bump, README feature markers, and related version references.---# Prepare a CLI11 releaseWhen preparing a release (`chore: prepare X.Y.Z release`):## Collect the changesList the merged PRs since the last release with`git log --oneline --first-parent v<last>..main`. Every user-visible change getsa changelog line.## Changelog entryAdd a `## Version X.Y.Z: <Short title>` section at the top of `CHANGELOG.md`.The heading becomes the name of the GitHub release, so give it a short title,such as `## Version 2.7.0: Audit and documentation`.- Start with a short prose paragraph that summarizes the release.- Group the entries under `### Added`, `### Changed`, `### Fixed`, `### Documentation`, and `### Internal` (and `### Removed`/`### Deprecated` if needed). `Documentation` covers docs-only changes; `Internal` covers CI, tests, and tooling changes with no user-visible effect.- Reference PRs as `[#1305][]` and put the matching link definitions (`[#1305]: https://github.com/CLIUtils/CLI11/pull/1305`) at the end of the version section — each section keeps its own definitions so an extracted section needs no fixup.## Version bumpBump `include/CLI/Version.hpp`: the `CLI11_VERSION_MAJOR`/`MINOR`/`PATCH` macrosand the `CLI11_VERSION` string.## Other files- Only if not a patch release: Update the feature markers in `README.md`: remove the old 🆕 markers (the previous release's features) and change 🚧 markers (main-only features) to 🆕. Removing an emoji from a heading also changes its TOC anchor — drop the trailing `-` from the matching TOC links.- Check the copyright year in `LICENSE` and the version in `book/chapters/installation.md`.## VerifyCI extracts the release notes from the changelog on every build, so a versionbump without a matching changelog section fails. Check locally:```bashpython3 scripts/ExtractReleaseNotes.py --title "$(python3 scripts/ExtractVersion.py)"python3 scripts/ExtractReleaseNotes.py "$(python3 scripts/ExtractVersion.py)"```## After the PR mergesTell the user to tag the merge commit as `vX.Y.Z` and push the tag. CI thencreates the GitHub release: the name comes from the changelog heading, the bodyfrom the changelog section, and the single header plus source packages areattached automatically.

Frequently asked questions

Prepare Release