ousiass release
前提条件
- Claude Code 環境
git,ghCLI
引数
- バージョン (例:
/release v1.2.0): 指定バージョンでリリース - バージョンタイプ (例:
/release patch): 現在のバージョンから自動決定 - 引数なし: 変更内容からバージョンタイプを提案しユーザーに確認
フェーズ0: リリースオプションの確認
0-1. マニフェスト検出
プロジェクトルートで以下を検出し、publish 候補を特定する：
| マニフェスト | レジストリ | publish コマンド |
|---|---|---|
package.json |
npm | npm publish |
pyproject.toml / setup.py |
PyPI | python -m build && twine upload dist/* |
Cargo.toml |
crates.io | cargo publish |
*.gemspec |
RubyGems | gem build && gem push |
*.csproj / *.nuspec |
NuGet | dotnet pack && dotnet nuget push |
mix.exs |
Hex | mix hex.publish |
monorepo（workspaces, pnpm-workspace.yaml, lerna.json）を検出した場合は、対象パッケージをユーザーに確認する。
以下のいずれかに該当する場合、publish は不要と判断しユーザーに聞かない：
package.jsonに"private": trueがある- CI ワークフロー（
.github/workflows/,Jenkinsfile,.gitlab-ci.ymlなど）に publish ステップが既にある - マニフェストに
versionフィールドがない - アプリケーション（ライブラリではない）と明らかに判断できる場合
0-1b. CI リリース検出
CI ワークフロー（.github/workflows/, Jenkinsfile, .gitlab-ci.yml など）を走査し、CI が GitHub Release を作成するかを判定する。
以下のいずれかを検出した場合、CI がリリースを作成すると判断する（ci_creates_release = true）：
goreleaser/goreleaser-action（GoReleaser）softprops/action-gh-releasencipollo/release-actiongh release createをワークフロー内で実行している- その他、GitHub Release を作成する Action やスクリプト
ci_creates_release = true の場合、フェーズ6 で gh release create をスキップする（タグ push で CI に委ねる）。
0-2. ユーザー確認
AskUserQuestion で以下を確認：
- ブランチマージ: リリース前にブランチをマージするか（マージ元・マージ先も確認）
- バイナリビルド: ビルド成果物を添付するか（ビルドコマンドと成果物パスも確認）
- レジストリ publish: マニフェストが検出され、かつ上記の「不要」条件に該当しない場合のみ表示。「<レジストリ名> に publish しますか？」と確認（OTP 要否、scoped パッケージの
--access publicなども必要に応じて確認）
フェーズ1: マージ（該当時のみ）
- マージ元ブランチが最新か確認する（
git fetch && git log） - マージ先にチェックアウト →
git merge --no-ff <マージ元> - コンフリクトがあればユーザーに報告して中断
フェーズ2: 変更内容の収集
- 最新のリリースタグを取得する（
gh release list/git tag） - 前回リリースから現在までのコミット・マージ PR を収集
- 変更カテゴリ（
templates/changelog.mdを参照）で分類する
フェーズ3: バージョン決定
- 引数でバージョン指定あり → そのまま使用
- 指定なし → 変更内容から提案：
- 破壊的変更あり → major
- 新機能あり → minor
- バグ修正・改善のみ → patch
- ユーザーに確認し合意を得る
フェーズ4: Changelog 生成
CHANGELOG.mdが存在するか確認（なければ新規作成、あれば先頭に追記）templates/changelog.mdの形式で追記する- 各エントリは
英語 / 日本語の日英併記。コミットメッセージから生成
フェーズ5: バージョン更新（レジストリ publish 時のみ）
マニフェストファイルのバージョンを更新する：
| レジストリ | 更新対象 | 方法 |
|---|---|---|
| npm | package.json の version |
npm version <ver> --no-git-tag-version |
| PyPI | pyproject.toml の version / setup.py |
直接編集 |
| crates.io | Cargo.toml の version |
直接編集 |
| RubyGems | gemspec の version |
直接編集 |
| NuGet | csproj の Version |
直接編集 |
| Hex | mix.exs の version |
直接編集 |
lock ファイル（package-lock.json, Cargo.lock など）も更新が必要な場合は適切に対応する。
フェーズ5b: ビルド（該当時のみ）
- ビルドコマンドを実行
- 成果物の存在を確認
- 失敗時はユーザーに報告して中断
フェーズ6: リリース作成
- Changelog をコミット（
docs: v<バージョン> の changelog を追加） - タグを作成（
git tag v<バージョン>） - プッシュ（
git push && git push --tags） ci_creates_release = falseの場合:gh release create v<バージョン>でリリース作成（成果物があれば添付）ci_creates_release = trueの場合: タグ push で CI がリリースを作成するため、gh release createはスキップ。ユーザーに「CI がリリースを作成します」と報告する- リリース URL をユーザーに報告（CI 委譲時は CI ワークフローの URL を案内）
フェーズ7: レジストリ publish（該当時のみ）
フェーズ0 で publish を承認された場合のみ実行。
- dry-run で事前確認（
npm publish --dry-run,twine check dist/*など） - dry-run の結果をユーザーに表示し、最終確認を取る
- publish を実行
- publish 後、レジストリ上のパッケージ URL をユーザーに報告
レジストリ別コマンド：
| レジストリ | dry-run | publish |
|---|---|---|
| npm | npm publish --dry-run |
npm publish（scoped は --access public） |
| PyPI | twine check dist/* |
twine upload dist/* |
| crates.io | cargo publish --dry-run |
cargo publish |
| RubyGems | gem build *.gemspec |
gem push *.gem |
| NuGet | dotnet pack |
dotnet nuget push |
| Hex | mix hex.publish --dry-run |
mix hex.publish |
OTP が必要な場合はユーザーに入力を求める。
ルール
- バージョンは必ずユーザーの合意を得てから確定する
- Changelog は事実ベース。コミットメッセージや PR タイトルを元にする
- 破壊的変更は必ず ⚠️ セクションに明記する
- リモートへのプッシュ・リリース作成の前にユーザーに確認する
- TaskCreate/TaskUpdate で進捗を管理する