bump-release
paulrberg/agent-skills
Cut releases with version bumps, changelogs, commits, and tags for single packages or monorepos.
What is bump-release?
Automates the release workflow: bumps semantic versions, generates changelog entries, commits changes, and creates annotated tags. Supports single-package repos, monorepos, stable and beta releases, and dry-run previews.
- Discovers releasable packages and inspects changed files since the last tag
- Decides version bumps (patch/minor/major) based on consumer-facing changes
- Generates changelog entries from the bounded diff and validates their structure
- Updates package manifests and dependency ranges across workspaces
- Creates one commit and annotated tag per package in dependency order
- Previews all actions in dry-run mode before writing files
How to install bump-release
npx skills add https://github.com/paulrberg/agent-skills --skill bump-release- Node.js and npm or compatible package manager
- Git repository with clean working tree
- Valid package.json or workspace configuration
- Existing CHANGELOG.md files for changelog validation
How to use bump-release
- 1.Run the skill with optional package names, version, and flags (--beta, --dry-run)
- 2.Review the discovery output showing changed files and previous tags
- 3.Decide stable version bumps (patch/minor/major) for each target package
- 4.Run the finalizer to resolve workspace dependencies and validate ranges
- 5.For dry-run, review the action preview; for release, confirm the plan
- 6.Validate changelogs, update manifests, format, commit, and tag in dependency order
- 7.Push tags with the provided git push command and optionally create GitHub releases
Use cases
- Release a single package with automatic changelog and git tag
- Cut releases across multiple packages in a monorepo with dependency ordering
- Create beta prerelease versions with `-beta.X` suffixes
- Preview a release plan without modifying files or committing
- Release with explicit semver versions when needed
- Package maintainers managing releases
- Monorepo maintainers coordinating multi-package releases
- Teams automating release workflows in CI/CD
- Developers needing changelog validation and dependency resolution
bump-release FAQ
The skill stops immediately and requires a clean working tree before proceeding.
Yes, the skill supports monorepos and will order commits and tags by dependency, resolving workspace edges automatically.
It previews all planned actions—version bumps, changelog entries, commits, and tags—without modifying files or creating commits.
The agent inspects the bounded diff since the previous tag, reads common-changelog.md for reference, and writes consumer-facing entries with category and importance decisions.
The finalizer reports unsatisfied edges; you choose dependency policy and add dependent packages to the release set, then rerun until resolved.
Full instructions (SKILL.md)
Source of truth, from paulrberg/agent-skills.
argument-hint: "[packages...] [version] [--beta] [--dry-run]" disable-model-invocation: true effort: high model: sonnet name: bump-release user-invocable: true description: "Cut a release: bump versions, write changelogs, commit, tag."
Bump Release
If these instructions are already present in the conversation from a slash or dollar invocation, follow them directly; do not invoke this skill again through a skill tool.
Release one package or several packages with version bumps, changelog entries, commits, and tags. Supports single-package repositories, workspace monorepos, stable releases, beta releases, and dry runs.
Arguments
packages: optional package names or directories. Omit in a single-package repository.version: optional explicit semver. Valid only for one user-selected package.--beta: create or advance a-beta.Xprerelease.--dry-run: preview without modifying files, committing, or tagging.
Helper Interface
Resolve <skill-dir> from this SKILL.md. Keep helper stdout as JSON and diagnostics on stderr.
node "<skill-dir>/scripts/plan-release.mjs" \
[--cwd <repo>] [--beta] [--dry-run] [--version <semver>] \
[--package <name-or-dir>]...
The read-only discovery output has schemaVersion: 2. It reports package identity, complete per-package changedFiles,
workspace edges and declared ranges, previous-tag facts, selected targets, and worktree state. changeHints are
filename-based, explicitly non-authoritative navigation hints. Never use them to decide release relevance or changelog
inclusion.
After the agent decides every stable patch/minor/major version, write discovery JSON to a temporary file and run:
uv run "<skill-dir>/scripts/finalize-release-plan.py" \
--discovery <discovery.json> \
[--version <package>=<semver>]...
The finalizer performs beta and explicit-version transitions, stable prerelease promotion, npm-range satisfaction,
simple dependency-range suggestions, and dependency ordering. It reports complex ranges, peer ranges, dependency cycles,
and stable versions not supplied by the agent as unresolved decisions. When an unsatisfied edge adds a dependent, choose
that package's release version and rerun with another --version assignment. The finalizer never chooses a regular
release magnitude or dependency policy.
For every stable changelog written, validate its deterministic structure:
uv run "<skill-dir>/scripts/validate-changelog.py" \
--file <CHANGELOG.md> --version <semver> --date <YYYY-MM-DD> [--tag <tag>]
This checks the expected release and date, heading/category order, allowed categories, list structure, and release-link tag. It does not judge importance, wording, or semantic category.
Workflow
-
Run discovery with the user arguments mapped directly. Exit
2means the target is not a releasable Git/package repository; exit64means invalid input. Stop on either. -
Require
workingTree.clean. Do not absorb unrelated work. -
Resolve unknown or ambiguous package selection. An explicit user version remains single-package only.
-
Inspect each target's complete
changedFilesand the net diff from its previous tag. Decide whether the surviving changes warrant a release. Runtime environments, refactors, documentation, tests, and tooling can all be relevant in context; filenames never decide this. -
For every relevant stable target without an explicit version, choose patch, minor, or major from the consumer-facing change. For beta releases, let the finalizer compute the mechanical transition.
-
Run the finalizer. Review unsatisfied workspace edges. Accept its suggestion only for a simple dependency range when that policy fits; choose peer and complex range policy explicitly. Add dependents and their agent-chosen release versions, then rerun until the package set and dependency order are resolved.
-
For a dry run, report the ordered package/version plan, range edits, changelog/tag/commit actions, and agent-decided skips. Stop before writes.
-
For a stable release, read
references/common-changelog.mdand write consumer-facing entries from the bounded net diff. The agent owns entry selection, wording, importance, and category. Beta releases do not update changelogs. -
Update manifests and accepted dependency ranges. Validate every stable changelog with the helper.
-
Format once using the repository's narrowest established command.
-
Commit and tag dependencies before dependents. Use one commit and one annotated tag per package:
- single-package commit:
docs: release <version>; - monorepo commit:
docs: release <package> <version>; - single-package tag: follow observed
v<version>or bare-semver facts; - monorepo tag: follow observed package tag facts, defaulting to
<package-dir>@<version>.
- single-package commit:
-
Do not push. After success, recommend an exact
git push origin <tag>...command containing only the tags created by this execution; do not use--tags. -
Before the final report, inspect
.github/workflows/for an active workflow that creates or publishes GitHub releases from pushed tags. A filename such asrelease.ymlis a hint, not proof. Use$cli-ghread-only to check whether the repository has an established history of maintained GitHub releases. If it does, offer to create a GitHub release for each new tag, pending the user's approval, according to these rules:- One tag and release CI exists: do not offer manual release creation; the tag push should trigger CI.
- One tag and no release CI exists: offer to create the release with
$cli-gh. - Multiple tags will be pushed together: offer to create one release per tag with
$cli-gheven when release CI exists, because the multi-tag push is not expected to trigger that automation reliably.
Never create a GitHub release without the user's approval. If release history cannot be verified, report it as unknown and do not offer the write.
Safety and Completion
Helper failures mean malformed input, violated invariants, or failed validation; an agent decision remaining unresolved is data in the JSON, not a helper failure. Discovery and dry-run are read-only. Do not write changelogs before the final stable package set is known, and do not infer a tag convention when discovery reports observed facts.
Dry-run completion requires a discovery-backed, agent-reviewed action preview with zero writes. Release completion requires validated manifests and stable changelogs, formatting, one commit and annotated tag per package in dependency order, and a report of created commits/tags, agent-decided skips, the exact tag-push command, and any applicable GitHub release proposal.
Use ### ⛔ Release stopped — working tree is not clean, ### ⚠️ Confirm release plan,
### 🔎 Release preview — no files, commits, or tags written, or ### 🏁 Release complete as applicable. Keep helper
JSON, versions, hashes, tags, commands, and changelog text exact and undecorated.
Related skills
More from paulrberg/agent-skills and the wider catalog.

cli-gh
GitHub CLI automation for repository reads, workflows, search, codespaces, and releases.

code-polish
Polish and review changed code with risk-profiled simplification and defect detection.

code-review
Find high-impact defects in code reviews, PRs, and diffs with evidence-based severity ranking.

code-simplify
Simplify and refactor code while preserving behavior, clarity, and maintainability.

effect-ts
Apply Effect 3 semantics for services, layers, typed errors, Schema, Config, and runtime patterns.

md-docs
Initialize and update README.md and AGENTS.md documentation for Claude Code workflows.