ソース情報
- リポジトリ
- iopsystems/rezolus
- ソースの最終更新活動
- 2026年6月5日 20:36
- 検出された SKILL.md の言語
- 英語
- スター
- 272
- フォーク
- 21
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/iopsystems/rezolus --skill releaseコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
Ensure site/viewer/lib has correct symlinks to src/viewer/assets/lib
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.
SOC 職業分類に基づく
SKILL.md を表示中
| 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