無料GitHub で公開

prerelease

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.

iopsystems/rezolus

インストール方法を見る

含まれるファイル（1）

SKILL.md2.0 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Tag and push a prerelease to upstream (iopsystems/rezolus).

The release.yml CI workflow triggers on any v* tag push and automatically marks the GitHub release as a pre-release when the tag contains - (e.g. -alpha.8). Package registries and Homebrew are only updated for stable releases.

Steps

Verify prerequisites:

Must be on main branch
Working directory must be clean

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

Read version and validate it is a prerelease:

VERSION=$(grep '^version = ' Cargo.toml | head -1 | sed 's/version = "\(.*\)"/\1/')
echo "Current version: $VERSION"

if [[ "$VERSION" != *"-"* ]]; then
  echo "Error: $VERSION looks like a stable release (no prerelease suffix)."
  echo "Stable releases are handled by the tag-release CI workflow."
  echo "Commit with message 'release: prepare v$VERSION' on main instead."
  exit 1
fi

Check the tag does not already exist on upstream:

TAG="v$VERSION"
if git ls-remote --tags upstream "$TAG" | grep -q "$TAG"; then
  echo "Error: Tag $TAG already exists on upstream. Nothing to do."
  exit 1
fi

Create annotated tag and push to upstream:

echo "Creating prerelease tag $TAG and pushing to upstream."
echo "CI will build packages and create a GitHub pre-release."
git tag -a "$TAG" -m "Prerelease $TAG"
git push upstream "$TAG"

Report the GitHub release URL:

https://github.com/iopsystems/rezolus/releases/tag/$TAG

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

document-feature

無料

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.

日本語の概要は準備中です。原文の説明を表示しています。