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).