一键导入
release
Create a release PR with version bump and changelog update
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Create a release PR with version bump and changelog update
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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