release-crate

The release-crate skill provides a standardized, automated workflow for managing the lifecycle of Rust crates within the r3bl-open-core monorepo. Designed for maintainers and lead developers, this skill eliminates manual overhead and human error when preparing new versions of binary crates like cmdr or library crates such as tui. By enforcing a rigid sequence of operations, it ensures that every release adheres to the repository's internal quality standards and documentation requirements.

The skill guides the user through the identification of the target crate, version incrementing in Cargo.toml, and the maintenance of CHANGELOG.md files with proper TOC updates. It integrates seamlessly with the repository's testing infrastructure, executing full validation checks before any publishing attempt occurs. By managing git tagging and GitHub release creation as final steps, it provides a unified audit trail for every release event.

• Automates version management across workspace crates, supporting binary and library structures.

• Integrates with local check scripts (e.g., check.fish) to ensure build, test, docs, clippy, and fmt compliance before proceeding.

• Automates changelog formatting, including version entries and table of contents updates.

• Facilitates dry-run publishing to crates.io to verify metadata and packaging configurations before the final push.

• Handles git tagging and generates structured GitHub release notes using custom templates.

• Provides a safeguard mechanism by explicitly requiring user authorization before executing non-reversible publishing actions.

• Before invocation, ensure all code changes are pushed and the local environment is clean.

• The skill expects the crate directory name as an argument; it automatically detects whether it is a library or binary crate to determine if cargo install is required post-publish.

• Always verify the current version in Cargo.toml prior to starting the process.

• Use the --no-verify flag during dry-run stages to bypass specific linker issues encountered with custom build configurations.

• If the workspace environment changes or new scripts are added, reference docs/release-guide.md for updated canonical release procedures.