Release スキル
軽量でリポジトリを認識するリリースアシスタント。初回実行時はプロジェクトとCIを検査してリリースルールを導出し、.omc/RELEASE_RULE.md に保存、その後はそのルールに従ってリリースをガイドします。
使用方法
/oh-my-claudecode:release [version]
versionはオプション。省略した場合、スキルが確認を行います。patch、minor、major、または2.4.0のような明示的なセマバーを受け付けます。--refreshを追加すると、キャッシュされたルールファイルが存在する場合でもリポジトリの再分析を強制します。
実行フロー
ステップ0 — リリースルールのロードまたは構築
.omc/RELEASE_RULE.md が存在するか確認します。
存在しない場合（または --refresh が指定された場合）： 以下の完全なリポジトリ分析を実行し、ファイルを書き込みます。
存在する場合： ファイルを読み取ります。次に、.github/workflows/ （または同等のCIディレクトリ: .circleci/、.travis.yml、Jenkinsfile、bitbucket-pipelines.yml、gitlab-ci.yml）をスキャンして、ルールファイルの 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（
package.jsonにpublishConfigがある、または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
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->
## Version Sources
<!-- ファイルとパターンのリスト -->
## Release Trigger
<!-- リリースを開始するもの -->
## Test Gate
<!-- コマンド + CIジョブ名 -->
## Registry / Distribution
<!-- npm、PyPI、Dockerなど + 公開するCIジョブ -->
## Release Notes Strategy
<!-- 規約 + ファイル -->
## CI Workflow Files
<!-- 関連するワークフローファイルへのパス -->
## First-Time Setup Gaps
<!-- 分析中に見つかった欠落部分、または「none」 -->
ステップ3 — バージョンの決定
ユーザーがバージョン引数を指定した場合はそれを使用します。そうでない場合：
- 現在のバージョン（プライマリバージョンファイルから）を表示します。
patch、minor、majorで生成されるバージョンを表示します。- ユーザーにどれを使用するか尋ねます。
選択されたバージョンが有効なセマバー文字列であることを検証します。
ステップ4 — リリース前チェックリスト
リリースルールに基づいてチェックリストを表示します。最低限：
- このリリースに含めるすべての変更がコミットされ、プッシュされている
- ターゲットブランチのCIがグリーンである
- ローカルでテストがパスする（テストゲートコマンドを実行）
- すべてのバージョンソースファイルにバージョンアップが適用されている
- リリースノート/チェンジログが準備されている（ステップ5参照）
ユーザーに確認を求め、続行するか、「go ahead」と言った場合は各ステップを実行します。
ステップ5 — リリースノートガイダンス
ユーザーが良いリリースノートを作成できるよう支援します。リポジトリが使用する規約があればそれを適用します。規約が検出されない場合のデフォルトガイダンス：
良いリリースノートの条件：
- ユーザーにとって何が変わったかを先頭に、内部実装の詳細は後回しにします。
- タイプ別にグループ化：
新機能、バグ修正、破壊的変更、非推奨、内部/雑務。 - 各項目は1文で、PRまたはIssueへのリンク、外部貢献者のクレジットを記載します。
- 破壊的変更は最初に記載し、移行パスを含める必要があります。
- ユーザーが目にしない変更（リファクタリング、CI調整、テストのみの変更）は、ビルドの再現性に影響を与える場合を除き省略します。
エントリ形式の例：
### バグ修正
- トークン期限切れによるセッション切断を修正 (#123) — @contributor
リポジトリがConventional Commitsを使用している場合、`git log ..HEAD --no-merges --format=