release について
リポジトリを把握するリリース支援スキルです。プロジェクトとCIを調査してルールを記録し、その後のリリースを案内します。ルールは `.omc/RELEASE_RULE.md` に保存され、CIファイルの変更に応じて再分析できます。
主な機能
- 01バージョン情報源と自動化の調査
- 02配布先とリリース開始条件の特定
- 03テスト要件と変更履歴規約の記録
- 04リポジトリのリリースルール保存と更新
- 05リリース実行と検証の案内
活用シーン
- 01初回のリリース手順の把握
- 02patch、minor、majorリリースの計画
- 03CI変更後のルール再分析
- 04導出したチェックリストに沿ったリリース
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/releaseを入力して読み込まれたか確認します。
詳細
リリーススキル
リポジトリを考慮したシンプルなリリースアシスタントです。初回実行時にプロジェクトと CI を調査してリリースルールを導き出し、今後のために .omc/RELEASE_RULE.md に保存します。その後、そのルールに従ってリリースを進めます。
使用方法
/oh-my-claudecode:release [version]
versionは省略可能です。省略した場合はスキルから確認します。patch、minor、major、または2.4.0のような明示的な semver を指定できます。- キャッシュされたルールファイルが存在する場合でも、リポジトリの再分析を強制するには
--refreshを追加します。
実行フロー
ステップ 0 — リリースルールの読み込みまたは作成
.omc/RELEASE_RULE.md が存在するか確認します。
存在しない場合（または --refresh が指定された場合）： 以下のリポジトリ全体の分析を実行し、ファイルに書き込みます。
存在する場合： ファイルを読み込みます。その後、差分を簡易確認します。.github/workflows/（または .circleci/、.travis.yml、Jenkinsfile、bitbucket-pipelines.yml、gitlab-ci.yml などの同等の CI ディレクトリ）をスキャンし、ルールファイルの last-analyzed タイムスタンプより新しい変更がないか確認します。関連するワークフローファイルが変更されている場合は、該当セクションを再分析してファイルを更新します。変更内容を報告します。
ステップ 1 — リポジトリの分析（初回実行時または --refresh）
リポジトリを調査し、以下の項目に回答します。回答を .omc/RELEASE_RULE.md に書き込みます。
1a. バージョンの参照元
package.json/pyproject.toml/Cargo.toml/build.gradle/VERSIONファイルなどで、現在のバージョンと一致するバージョン文字列を含むファイルをすべて特定します。- 各ファイルと、バージョンの特定に使用したフィールドまたは正規表現パターンを列挙します。
- リリース自動化スクリプト（例：
scripts/release.*、Makefile releaseターゲット、bump2version、release-it、semantic-release、changesets、goreleaser）があるか確認します。
1b. レジストリ／配布
- npm（
publishConfigを含むpackage.json、または CI でのnpm publish）、PyPI（pyproject.tomlとtwine／flit）、Cargo（Cargo.toml）、Docker（Dockerfileとプッシュステップ）、GitHub Packages、その他。 - タグのプッシュ時に自動公開する CI ステップがあるか確認します。該当するワークフローファイルとジョブを特定します。
1c. リリースのトリガー
- リリースの開始条件を特定します。タグのプッシュ（
v*）、手動ディスパッチ（workflow_dispatch）、main/master へのマージ、リリースブランチのマージ、コミットメッセージのパターンなどです。
1d. テストのゲート
- テストコマンドと、CI のどこで実行されるかを特定します。
- 公開前にテストの合格が必須か確認します。回避フラグがあれば記載します。
1e. リリースノート／変更履歴
CHANGELOG.mdまたはCHANGELOG.rstが存在するか確認します。- 使用されている規約を確認します。Keep a Changelog、Conventional Commits、GitHub の自動生成、規約なしなどです。
- タグ付け前にコミットされるリリース本文ファイル（例：
.github/release-body.md）があるか確認します。
1f. 初回ユーザーチェック
.github/workflows/（または同等の場所）にリリースワークフローがあるか確認します。ない場合は、その旨を通知し、ひな形の作成を提案します。- ビルド成果物のコミットを防ぐ
.gitignoreエントリがあるか確認します。ない場合は、その旨を通知します。 - Git タグが使われているか確認するため、
git tag --listを実行します。タグがない場合は、その旨を通知し、ベストプラクティスを説明します。
ステップ 2 — .omc/RELEASE_RULE.md の書き込み
以下の構成でファイルを作成または上書きします。
# Release Rules
## Version Sources
## Release Trigger
## Test Gate
## Registry / Distribution
## Release Notes Strategy
## CI Workflow Files
## First-Time Setup Gaps
ステップ 3 — バージョンの決定
ユーザーがバージョン引数を指定した場合は、それを使用します。指定していない場合は、以下を行います。
- 現在のバージョン（主要なバージョンファイルから取得）を表示します。
patch、minor、majorにした場合のバージョンを表示します。- どれを使うかユーザーに尋ねます。
選択されたバージョンが有効な semver 文字列か検証します。
ステップ 4 — リリース前チェックリスト
リリースルールに基づいてチェックリストを提示します。最低限、以下を含めます。
- このリリースに含めるすべての変更がコミットされ、プッシュされている
- 対象ブランチの CI が成功している
- ローカルでテストに合格している（テストゲートのコマンドを実行）
- すべてのバージョン参照元ファイルにバージョン変更が適用されている
- リリースノート／変更履歴が準備されている（ステップ 5 を参照）
続行する前にユーザーに確認を求めるか、「go ahead」と言われた場合は各ステップを実行します。
ステップ 5 — リリースノートの作成ガイド
ユーザーに適切なリリースノートを作成できるよう支援します。リポジトリで使用されている規約に従ってください。規約が見つからない場合のデフォルトのガイドラインは次のとおりです。
適切なリリースノートの条件：
- 内部の実装詳細ではなく、ユーザーにとって何が変わったかを最初に記載します。
- 種類ごとに分類します：
New Features、Bug Fixes、Breaking Changes、Deprecations、Internal / Chores。 - 各項目は1文にまとめ、PR または issue へのリンクを付け、外部のコントリビューターには謝辞を記載します。
- 破壊的変更は最初に記載し、移行方法を必ず含めます。
- ビルドの再現性に影響しない限り、ユーザーから見えない変更（リファクタリング、CI の調整、テストのみの変更）は記載しません。
項目の形式例：
### Bug Fixes
- Fix session drop on token expiry (#123) — @contributor
リポジトリで Conventional Commits を使用している場合は、git log <prev-tag>..HEAD --no-merges --format="%s" からコミットの種類ごとに分類した変更履歴の下書きを生成します。それをユーザーに提示し、編集できるようにします。
ステップ 6 — リリースの実行
確認したルールに従って、次の手順を進めます。
- バージョンを更新 — 各バージョン定義ファイルに適用します。
- テストを実行 — テストゲートのコマンドを実行します。
- コミット —
git add <version files> CHANGELOG.mdを実行し、chore(release): bump version to vX.Y.Zというメッセージでコミットします。 - タグを付ける —
git tag -a vX.Y.Z -m "vX.Y.Z"を実行します（軽量タグより注釈付きタグが推奨されます）。 - プッシュ —
git push origin <branch> && git push origin vX.Y.Zを実行します。 - CI による処理 — リリースのトリガーがタグのプッシュの場合、残りの処理（公開、GitHub リリースの作成）は CI が行うことをユーザーに伝えます。想定される CI ワークフローファイルを提示します。
- 手動で公開 — CI による自動化がない場合は、手動での公開コマンド（例：
npm publish --access public、twine upload dist/*）を示します。
ステップ 7 — 初回セットアップの提案
ステップ 1f で不足が見つかった場合は、具体的な対応を提案します。
リリースワークフローがない場合：
リポジトリにリリース用の CI ワークフローがありません。
v*タグのプッシュをトリガーとする GitHub Actions ワークフローが、最も一般的なベストプラクティスです。次の処理を実行できます。
- テストを実行する
- npm／PyPI などに公開する
- リリースノート付きの GitHub Release を作成する
使用している技術スタックに合わせて
.github/workflows/release.ymlを作成しましょうか？
Git タグがない場合：
これが初回リリースのようです。Git タグを使うと、GitHub、npm などのツールがバージョン履歴を認識できるようになります。ステップ 6 で最初のタグを作成します。
ビルド成果物が Git の追跡対象から除外されていない場合：
ビルド成果物が Git の履歴に含まれているか、Git の追跡対象から除外されていません。これによりリポジトリのサイズが大きくなり、マージの競合が発生します。
.gitignoreに追加しましょうか？
ステップ 8 — 確認
プッシュ後、次の項目を確認します。
- CI のステータスを確認します：
gh run list --workflow=<release workflow> --limit=3（ghが利用可能な場合）。 - 数分後、新しいバージョンがレジストリ（npm、PyPI）に反映されていることを確認します。
- GitHub Release が作成されたことを確認します：
gh release view vX.Y.Z。
成功した場合はその旨を報告し、失敗があればその内容を伝えます。
注記
- このスキルでは、プロジェクト固有のバージョン定義ファイルやコマンドをハードコードしません。すべてリポジトリの調査結果に基づいて決定します。
.omc/RELEASE_RULE.mdはローカルキャッシュです。導出されたルールをチームで共有する場合はリポジトリにコミットし、ローカルにのみ保持する場合は.gitignoreに追加してください。- 複雑なモノレポやマルチパッケージワークスペースでは、このスキルがワークスペースのパターン（npm workspaces、pnpm workspaces、Cargo workspace）を検出し、それに応じて対応します。