with one click
release
Create a release PR with version bump and changelog update
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Create a release PR with version bump and changelog update
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when adding or changing what the rezolus viewer exposes — an /api/v1 endpoint, a dashboard section, the metric catalog, metadata/description derivation, or the frontend data those depend on — or when editing src/viewer/ or crates/viewer/, or reviewing a viewer change. The viewer ships as two separate Rust backends (server + WASM) behind one shared frontend; changing one silently diverges them.
Use when starting or picking up a non-trivial effort (feature, investigation, perf probe, refactor, migration) in a shared repo where teammates or future agents must coordinate or hand off; when a repo has no durable in-tree record of decisions and dead-ends; when you're about to drop a well-measured negative result; or when bootstrapping a journal from a repo's commit history.
Use when reviewing a Rezolus sampler change before merge — a new sampler, a change to an existing sampler's probes/refresh/metrics, or core changes that affect samplers; or whenever a sampler's overhead, cadence, or data source is in question.
Write or update the CLI `--help` text and README section for a new or changed rezolus feature (a subcommand, flag, mode, or behavior change), then prove the help is usable by dispatching a fresh subagent that has never seen the code. Use this whenever you add or change how rezolus is invoked — new `rezolus <subcommand>`, new flags/args on an existing mode, renamed options, or changed defaults — and any time the user says the help/README is thin, stale, confusing, or "an agent couldn't figure this out." Treats help text as an interface under test, not prose.
Tag and push a prerelease from the current Cargo.toml version. Use when the user wants to cut an alpha/beta/rc prerelease. Aborts on stable versions (no `-` in version string) and if the tag already exists.
Create a feature branch, commit changes, push, and open a PR against iopsystems/rezolus
| name | release |
| description | Create a release PR with version bump and changelog update |
Create a release PR that bumps the version and updates the changelog. After the PR is merged, a GitHub workflow will automatically tag the release, create a GitHub release, and bump to the next development version.
The skill accepts a version level argument:
patch - 5.5.0 -> 5.5.1minor - 5.5.0 -> 5.6.0major - 5.5.0 -> 6.0.05.6.0Example: /release minor
Verify prerequisites:
main branchgit fetch origin
if [ "$(git branch --show-current)" != "main" ]; then
echo "Error: Must be on main branch"
exit 1
fi
if [ -n "$(git status --porcelain)" ]; then
echo "Error: Working directory not clean"
exit 1
fi
if [ "$(git rev-parse HEAD)" != "$(git rev-parse origin/main)" ]; then
echo "Error: Not up to date with origin/main"
exit 1
fi
Run local checks:
cargo clippy --all-targets -- -D warnings
cargo test
If checks fail, stop and report the errors.
Determine the new version:
# Get current version from Cargo.toml (strip -alpha.N suffix if present)
CURRENT=$(grep '^version = ' Cargo.toml | head -1 | sed 's/version = "\(.*\)"/\1/')
echo "Current version: $CURRENT"
# Use cargo-release to calculate new version (handles alpha suffix removal)
cargo release version <LEVEL> --dry-run 2>&1 | grep -o '[0-9]\+\.[0-9]\+\.[0-9]\+' | head -1
Note: cargo-release will strip the -alpha.N suffix when bumping to a release version.
Create release branch:
NEW_VERSION="X.Y.Z" # from step 3
git checkout -b release/v${NEW_VERSION}
Bump version using cargo-release:
cargo release version <LEVEL> --execute --no-confirm
Update CHANGELOG.md:
[unreleased] link pointing to compare/vX.Y.Z...HEAD[X.Y.Z] link comparing to the previous versionThe changelog follows Keep a Changelog format. Ask the user if they want to review/edit the changelog before proceeding.
Commit changes:
git add -A
git commit -m "release: prepare v${NEW_VERSION}"
Push and create PR:
IMPORTANT: The PR title must start with release: prepare v so the
tag-release.yml workflow fires after merge. When the PR is
squash-merged (the repo default), the squash commit takes the PR
title as its message, and the workflow guard checks
startsWith(head_commit.message, 'release: prepare v'). A title like
release: v${NEW_VERSION} would NOT match and the tag/release would
be silently skipped.
git push -u origin release/v${NEW_VERSION}
gh pr create \
--repo iopsystems/rezolus \
--title "release: prepare v${NEW_VERSION}" \
--body "$(cat <<'EOF'
## Release v${NEW_VERSION}
This PR prepares the release of v${NEW_VERSION}.
### Changes
- Version bump in Cargo.toml
- Changelog update
### After Merge
The release workflows will automatically:
1. Create git tag `v${NEW_VERSION}` and bump to next dev version
2. Build and publish packages (deb, rpm, Homebrew)
3. Create GitHub release with all artifacts
4. Publish to crates.io
---
See CHANGELOG.md for details.
EOF
)"
Report the PR URL to the user.
When the PR is merged to main, the following workflow chain runs automatically:
tag-release.yml (triggered by push to main with release commit message):
vX.Y.Z5.5.1-alpha.0) and pushes to mainrelease.yml (triggered by the tag push):
cargo install cargo-releasebrew install gh or see https://cli.github.com/gh auth login