Release Bumper

If a slash or dollar invocation already added these instructions to the conversation, follow them directly. In that case, do not invoke this skill again through a skill tool.

Release one package or several packages with version bumps, changelog entries, commits, and tags.

A non-dry-run invocation authorizes the repository-local version edits, changelogs, commits, and annotated tags defined by this workflow. Do not add a generic confirmation gate after the agent derives the release plan. Ask only when an unresolved package selection or dependency-range policy changes the release set or approach. GitHub release creation remains a separate external write governed below.

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.X prerelease.
• --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.

bun run "<skill-dir>/scripts/plan-release.ts" \
  [--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

1. Run discovery with the user arguments mapped directly. Exit 2 means the target is not a releasable Git/package repository. Exit 64 means invalid input. Stop on either.
2. Require workingTree.clean. Do not absorb unrelated work.
3. Resolve unknown or ambiguous package selection. An explicit user version remains single-package only. If a target's previousTags version is below its manifest version, that version shipped untagged and the reported base is stale: create the missing annotated tag on its release commit (for example docs: release <version>) using the observed tag convention, include it in the push command, and rerun discovery. Ask only when no release commit is identifiable.
4. Inspect each target's complete changedFiles and 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.
5. 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.
6. 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.
7. For a dry run, report the ordered package/version plan, range edits, changelog/tag/commit actions, and agent-decided skips. Stop before writes.
8. For a stable release, read references/common-changelog.md and write consumer-facing entries from the bounded net diff. The agent owns entry selection, wording, importance, and category. Beta releases do not update changelogs.
9. Update manifests and accepted dependency ranges. Validate every stable changelog with the helper, in a single shell invocation that loops over the changelogs and reports each result.
10. Format once using the repository's narrowest established command.
11. 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>.
12. 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.

13. Before the final report, inspect .github/workflows/ once for both the criteria in this step and the criteria in step 14. For this step, look for an active workflow that creates or publishes GitHub releases from pushed tags. A filename such as release.yml is a hint, not proof. Use $cli-gh to run gh release list read-only in the same turn as that inspection and 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 to three tags and applicable release CI exists: do not offer manual release creation. In that case, the tag push should trigger CI.
    • No applicable release CI exists: offer to create one release per new tag with gh release create through $cli-gh.
    • More than three tags will be pushed together: offer to create one release per tag with gh release create through $cli-gh even when release CI exists, because GitHub does not create tag push events above that threshold. See GitHub's push-event limits.

    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.

14. Before the final report, also use the single .github/workflows/ inspection from step 13 to look for an active workflow that runs on pushed tags, sets id-token: write, and runs npm stage publish (staged) or npm publish (direct). A filename is a hint, not proof. If such a workflow exists:
    • Report that pushing the recommended tags triggers npm publication.
    • For staged publishing, report that each version stays unpublished until the maintainer approves it with 2FA. The maintainer can run npm stage approve <stage-id> or use the Staged Packages tab on npmjs.com.
    • Recommend push commands with at most three tags each, because GitHub creates no tag push events above that threshold. See the push-event limits link in step 13.
    • Never run npm publish, npm stage approve, or npm stage reject.

Safety and Completion

Helper failures mean malformed input, violated invariants, or failed validation. An unresolved agent decision 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 or commands, any applicable GitHub release proposal, and any CI npm publication notice.

Use ### ⛔ Release stopped — working tree is not clean, ### ⚠️ Release decision required, ### 🔎 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.