cm-release

Cuts signed, human-gated release and pre-release versions with a gated build and GitHub release.

3|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/PurdueRCAC/rcac-mcp --skill cm-release-purduercac
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cm-release
Source: https://github.com/PurdueRCAC/rcac-mcp/tree/main/.agents/skills/cm-release
Command: npx skills add https://github.com/PurdueRCAC/rcac-mcp --skill cm-release-purduercac

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Cutting a release involves irreversible steps — a published version string can never be reused — yet teams often bump versions and push tags ad hoc without a consistent gate. This Skill enforces a disciplined, human-confirmed release procedure for the rcac-mcp project so no bad build ever becomes a permanent tag. ## Core Features & Use Cases - Two release modes: release for final versions on main and pre-release for alpha/beta/rc versions flagged with --prerelease on the GitHub release. - Non-negotiable quality gate: runs pytest, uv build --no-sources, twine check --strict, and an sdist-hygiene check that blocks internal directories from shipping in the tarball. - Isolated dry-run rehearsal: rehearses the version bump and full gate in a detached git worktree before any real ref moves, with an explicit human confirmation required before the first push. - Use Case: A maintainer runs /cm-release release 0.2.0 to bump pyproject.toml, update uv.lock, sign an annotated tag, and publish a GitHub release — all verified before anything irreversible happens. ## Quick Start Ask the assistant to cut release version 0.2.0 of the project, confirming before any push or publish step.

Frequently Asked Questions about cm-release

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

FAQPage Schema
How do I cut a release with a signed git tag?

Use the release mode with an explicit version, such as release 0.2.0. The skill bumps pyproject.toml, runs the full test and build gate, creates a signed annotated tag with git tag -s, verifies it, and only pushes after your explicit confirmation.

How do I publish a pre-release on GitHub?

Use pre-release mode with a PEP 440 prerelease version like 0.2.0rc1. The skill runs the same gate as a final release but creates the GitHub release with the --prerelease flag, and PyPI keeps the last stable version as the default install.

Does this release process push to PyPI automatically?

No, PyPI upload is off by default. It only happens when you pass the --publish-pypi flag and explicitly confirm at the human gate, because a published version string on PyPI can never be reused.

What happens if the test or build gate fails during a release?

Any failure in pytest, uv build, twine check, or the sdist hygiene check is a hard stop. The skill never overrides a red gate to ship, and the dry-run rehearsal in an isolated git worktree means nothing in the real tree has moved.

Can the version number be auto-bumped or inferred?

No, the version must always be provided explicitly and is never inferred. It must be valid PEP 440, strictly greater than the latest tag, not already a tag, and consistent with the chosen mode (final for release, suffixed for pre-release).