release
リリースに必要な changelog 生成、バージョンタグ付け、GitHub リリースノートの作成を体系的に行うスキル。
引数
- •バージョン (例:
/release v1.2.0): 指定したバージョンでリリースを作成する - •バージョンタイプ (例:
/release patch,/release minor,/release major): 現在のバージョンから自動でバージョンを決定する - •引数なし: 変更内容からバージョンタイプを提案し、ユーザーに確認する
実行プロセス
フェーズ0: リリースオプションの確認
AskUserQuestion で以下を確認する:
- •ブランチマージ: リリース前にブランチをマージするか(例: develop → main)
- •「マージする」を選んだ場合、マージ元・マージ先のブランチ名も確認する
- •マージ後、マージ先ブランチ上でリリース作業を続行する
- •バイナリビルド: リリースにビルド成果物(バイナリ等)を添付するか
- •「添付する」を選んだ場合、ビルドコマンドと成果物のパス(glob 可)も確認する
フェーズ1: マージ(該当する場合のみ)
フェーズ0でマージを選択した場合のみ実行:
- •マージ元ブランチが最新か確認する(
git fetch && git log) - •マージ先ブランチにチェックアウトする
- •マージ元ブランチをマージする(
git merge --no-ff <マージ元>でマージコミットを残す) - •コンフリクトがあればユーザーに報告して中断する
フェーズ2: 変更内容の収集
- •最新のリリースタグを取得する(
gh release list/git tag) - •前回のリリースから現在までのコミット・マージ PR を収集する
- •
git log <前回タグ>..HEAD --oneline - •
gh pr list --state merged --search "merged:>YYYY-MM-DD"
- •
- •変更内容をカテゴリ別に分類する
変更カテゴリ
| カテゴリ | コミットの type | 説明 |
|---|---|---|
| ✨ 新機能 | feat | 新しい機能の追加 |
| 🐛 バグ修正 | fix | バグの修正 |
| 🔧 改善 | update, refactor | 既存機能の改善・リファクタリング |
| 📝 ドキュメント | docs | ドキュメントの更新 |
| 🧪 テスト | test | テストの追加・修正 |
| 🏗️ インフラ | ci, build | CI/CD、ビルド設定の変更 |
| ⚠️ 破壊的変更 | コミットメッセージに BREAKING を含む | 後方互換性のない変更 |
フェーズ3: バージョン決定
- •引数でバージョンが指定されていればそれを使う
- •指定されていない場合、変更内容から提案する:
- •破壊的変更がある → major を提案
- •新機能がある → minor を提案
- •バグ修正・改善のみ → patch を提案
- •提案をユーザーに確認し、合意を得る
フェーズ4: Changelog 生成
- •
CHANGELOG.mdが存在するか確認する- •存在しない場合は新規作成する
- •存在する場合は先頭に追記する
- •以下の形式で追記する
Changelog 形式
markdown
## [v1.2.0] - YYYY-MM-DD ### ✨ 新機能 - <PR タイトルまたはコミットメッセージ> (#PR番号) ### 🐛 バグ修正 - <PR タイトルまたはコミットメッセージ> (#PR番号) ### 🔧 改善 - <PR タイトルまたはコミットメッセージ> (#PR番号) ### 📝 ドキュメント - <PR タイトルまたはコミットメッセージ> (#PR番号) ### 🧪 テスト - <PR タイトルまたはコミットメッセージ> (#PR番号) ### 🏗️ インフラ - <PR タイトルまたはコミットメッセージ> (#PR番号) ### ⚠️ 破壊的変更 - <変更内容の説明> (#PR番号)
- •該当する変更がないカテゴリは省略する
- •PR 番号がある場合はリンク付きで記載する
フェーズ5: ビルド(該当する場合のみ)
フェーズ0でバイナリ添付を選択した場合のみ実行:
- •ユーザーが指定したビルドコマンドを実行する
- •成果物が指定パスに生成されたことを確認する
- •ビルドに失敗した場合はユーザーに報告して中断する
フェーズ6: リリース作成
- •Changelog の変更をコミットする
- •コミットメッセージ:
docs: v<バージョン> の changelog を追加
- •コミットメッセージ:
- •バージョンタグを作成する
- •
git tag v<バージョン>
- •
- •リモートにプッシュする
- •
git push && git push --tags
- •
- •GitHub リリースを作成する
- •
gh release create v<バージョン> --title "v<バージョン>" --notes-file - - •ビルド成果物がある場合はコマンド末尾に成果物パスを追加して添付する
- •リリースノートの内容は Changelog のそのバージョンのセクションを使用する
- •
- •リリース完了をユーザーに報告する(リリース URL を含める)
ルール
- •バージョンは必ずユーザーの合意を得てから確定する
- •Changelog は事実ベースで書く。コミットメッセージや PR タイトルを元にする
- •破壊的変更がある場合は必ず ⚠️ セクションに明記する
- •変更がないカテゴリは Changelog に含めない
- •リモートへのプッシュ・リリース作成の前にユーザーに確認する
- •各フェーズの進捗は TodoWrite ツールで管理する