mcpField
J
jackin-release

jackin-release

github.com/jackin-project開発3469 回インストール4 週間前に更新
リポジトリ

jackin-release について

jackin-release は、jackin❯ のバージョンを公開する担当者向けのリリーススキルです。準備状況の確認と変更履歴の作成を連携し、変更内容からバージョンを提案したうえで、取り消せないリリースコマンドの実行前に明示的な承認を求めます。

主な機能

  1. 01リリース準備状況のチェック
  2. 02未リリース変更履歴の作成と承認
  3. 03変更分類に基づくバージョン提案
  4. 04変更履歴の編集内容をコミット
  5. 05明示的な確認後にリリースを実行
  6. 06ローカルとリモートのタグ確認

活用シーン

  1. 01準備チェック通過後の新バージョン公開
  2. 02承認済み変更履歴に基づくバージョン決定
  3. 03リリース前の変更履歴の確認と承認
  4. 04リリース後のタグ確認とビルドワークフローの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jackin-project/jackin-dev --skill jackin-release

インストール後、Claude Code で/jackin-releaseを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

jackin-release

リリースを作成します。このスイートで唯一、取り消せない操作を行うスキルです。cargo release --execute はバージョンを更新し、変更履歴の見出しを書き換え、タグを作成してプッシュします。オペレーターの明示的な「はい」を必須条件としており、推測でリリースすることはありません。

jackin-release-check(ゲート)とjackin-release-notes(変更履歴)を実行し、変更履歴の内容に基づいてバージョンを推奨してからリリースを作成します。

使用する場合

  • オペレーターから、バージョンの作成/公開/リリースを依頼された場合。

使用しない場合

  • 準備状況の確認のみ → jackin-release-check。
  • 変更履歴の更新のみ → jackin-release-notes。

前提条件

cargo-release がインストール済みであること、gh の認証が済んでいること、CHANGELOG.md 用の pre-release-replacements を含む release.toml があること、`` マーカーを含む CHANGELOG.md があること、.github/workflows/ci.yml があること。

手順

  1. ゲート。 jackin-release-check を実行します。ゲートが赤の場合は停止し、レポートを提示して修正が必要な内容を伝えます。警告があれば提示し、続行するか確認します。

    完了条件 すべてのゲートが緑であるか、オペレーターが警告を了承していること。

  2. 変更履歴。 jackin-release-notes を実行します。[Unreleased] セクションを提示し、オペレーターが分類や表現を変更できるようにします。

    完了条件 オペレーターが変更履歴を承認していること。

  3. バージョンを推奨する。 承認済みの [Unreleased] の各分類を確認します。Removed または「breaking」に該当する項目があれば major、Added があれば minor、Fixed/Changed/Security/Deprecated のみであれば patch を選びます。現在のバージョン(grep '^version' Cargo.toml)を確認し、次のバージョンを計算して、推奨案を提示し、返答を待ちます。

    完了条件 オペレーターが更新レベルを確認していること。

  4. 変更履歴をコミットする。 CHANGELOG.md に未コミットの編集がある場合は、git add CHANGELOG.md && git commit -m "docs: update changelog for vX.Y.Z" を実行します。

  5. 最終確認。 バージョン、更新レベル、変更履歴の内容、これから実行する正確なコマンド cargo release <level> --execute を含む概要を提示します。このコマンドは、Cargo.toml を更新し、release.toml を使って [Unreleased] を [X.Y.Z] - <date> に変更し、タグを作成してプッシュします。明示的な「はい」がない限り実行しないでください。

    完了条件 オペレーターが「はい」と答えていること。

  6. リリースを作成する。 cargo release <level> --execute を実行します。失敗した場合は、エラーを提示して停止します。

  7. 確認する。 git tag -l "vX.Y.Z" と git ls-remote --tags origin "refs/tags/vX.Y.Z" を実行します。生成物をビルドするリリースワークフローをオペレーターに案内します。

エラーからの復旧

  • cargo release の実行前:安全に修正して再実行できます。このスキルはすべてを再検証します。
  • cargo release の実行中:何がコミットまたはタグ付けされたかを確認します。タグが作成済みで未プッシュの場合は、git push origin vX.Y.Z を実行します。タグなしでバージョンのコミットが作成された場合は、リセットして再試行します。
  • 実行後:リリースは完了しています。CI の失敗はワークフローの問題であり、ロールバックの対象ではありません。

よくある間違い

  • 明示的な「はい」を得ずに cargo release を実行すること。この唯一の厳格なゲートを必ず守ってください。
  • 準備状況のゲートが赤のままリリースを実行すること。
  • [X.Y.Z] のバージョン見出しを手動で編集すること。cargo-release は release.toml の pre-release-replacements を使って書き換えます。二重に編集すると、リリースのコミットが破損します。

コメント