bump-release

The bump-release skill provides an end-to-end automated solution for managing software project releases. It is designed to handle common release engineering tasks, such as calculating the next semantic version, updating the CHANGELOG.md file, and performing Git operations like committing and tagging. This tool is particularly effective for monorepo environments, as it allows users to specify which package to release and intelligently finds the relevant package.json and changelog files. Users can trigger regular releases or opt for beta releases using the --beta flag, which includes automated incrementing of beta tags like -beta.X. The skill also integrates with the 'just' command runner to perform post-versioning formatting, ensuring consistency across the codebase. With dry-run capabilities, developers can safely preview the entire release process, including version calculations and changelog updates, without impacting the repository. This skill is essential for developers aiming to standardize their release process, minimize manual errors, and maintain high-quality project documentation.

• Automatically determines the next version (PATCH, MINOR, MAJOR) based on semantic versioning rules.

• Generates structured CHANGELOG entries, grouping changes into Changed, Added, Removed, and Fixed categories.

• Ensures proper formatting by running project-specific tasks (e.g., 'just full-write') before committing.

• Supports explicit version overrides to skip inference when a specific release goal is required.

• Safely handles monorepo structures by allowing directory-specific targeting.

• Provides a dry-run mode for previewing changes without side effects.

• Works best when integrated into a standard Git-based development workflow.

• Requires a clean working tree; the skill can automatically invoke a commit skill if uncommitted changes are detected.

• Changelog updates are skipped for beta releases; only regular releases receive automated documentation updates.

• The tool leverages project-specific configuration files like package.json and relies on conventional commit histories for changelog generation.

• Always confirm inferred versions during the interactive step to ensure the release target meets project requirements.