Skip to main content

release-automation

Prepares and automates the release process for multi-storage-client (version bump, release notes, checklist). Use when the user wants to cut a release, bump version, prepare release, publish a new version, or automate release steps.

Source facts

Repository
NVIDIA/multi-storage-client
Last source activity
September 9, 2026 at 18:30
Detected SKILL.md language
English
Stars
87
Forks
28

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
release-automation
description
Prepares and automates the release process for multi-storage-client (version bump, release notes, checklist). Use when the user wants to cut a release, bump version, prepare release, publish a new version, or automate release steps.
# Release Automation Guides the agent through preparing a release for the multi-storage-client repository. Tagging is done by the pipeline after the release MR is merged; this skill covers only the in-repo changes (version bump, release notes). Do not ask the user to run `git tag` or push a tag. ## When to Use - User asks to "cut a release", "bump version", "prepare release", "publish new version", or "automate release". - User wants to move unreleased notes into a versioned file and bump the package version. ## Prerequisites - Work from repository root. - Ensure `.release_notes/.unreleased.md` has been updated with notable changes (per PR template). If empty or placeholder-only, confirm with the user before releasing. ## Release Preparation Workflow ### 1. Determine the new version - Read current version from `multi-storage-client/pyproject.toml` (`version = "X.Y.Z"`). - If the user specified a version (e.g. "0.44.0"), use it. Otherwise propose: - **Patch** (e.g. 0.43.0 → 0.43.1): bug fixes only. - **Minor** (e.g. 0.43.0 → 0.44.0): new features, backward-compatible. - **Major**: breaking changes (rare; confirm with user). ### 2. Bump package version - In `multi-storage-client/pyproject.toml`, set `version = "<new_version>"` (e.g. `"0.44.0"`). ### 3. Finalize release notes - Read `.release_notes/.unreleased.md`. - Read git history for changes since the last release: `git log <previous_version>..HEAD --no-merges --format='%h %s%n%b'` (tags are unprefixed, e.g. `0.42.0` not `v0.42.0`). Use this to find and add relevant entries; omit CI/CD, build, and chore-only commits. - Create `.release_notes/<new_version>.md` with that content (e.g. `.release_notes/0.44.0.md`). Preserve structure (Breaking Changes, New Features, Bug Fixes, etc.). - Skip mentioning any changes that are CI/CD related. - Reset `.release_notes/.unreleased.md` to its template (with `<!-- Add items here. -->` at the top). If unsure whether the repo convention expects a reset, ask the user before modifying. ### 4. Verification (recommended) - Run `just build` from repo root (runs analyze, unit tests, ray tests; in CI also runs package). ### 5. Handoff checklist Present a short checklist for the user: - [ ] Version bumped in `multi-storage-client/pyproject.toml`. - [ ] `.release_notes/<new_version>.md` created; `.release_notes/.unreleased.md` handled as above. - [ ] `just build` passed (or user will run locally). - [ ] Create a git commit with the release changes and open/merge an MR; the pipeline will create and push the tag after merge. ## Reference - Repo-specific paths and CI details: [reference.md](reference.md)
View on GitHub