Release Preparation Skill (Bump 適用版)

release-prep (read-mostly な確認) の続きとして、 実際の version bump 差分 を全 manifest にわたり生成する skill。

ユーザは memory feedback_conservative_changes.md / feedback_merge_caution.md に従い、 適用は明示確認を取ってから (デフォルト dry-run、 markdown diff 提示のみ)。

カバー範囲

引数

• $ARGUMENTS 1 つ目: all / python / rust / csharp / npm / swift / kotlin
• --target-version X.Y.Z: 次回リリース version (必須)
• --dry-run (default): markdown 出力のみ、 ファイル変更しない
• --apply: dry-run の確認後にユーザが追加で渡す flag。 これがある時のみ Edit を実行

現在の状態

• ブランチ: !git rev-parse --abbrev-ref HEAD
• 引数: $ARGUMENTS
• 直近 tag: !git tag --sort=-v:refname | head -3

フェーズ 1: 現 manifest version 読み出し (9 ファイル)

並列で Read し、 各 manifest の現 version を抽出:

フェーズ 2: 既存 sync gate との交差確認

uv run python scripts/check_voice_catalog_parity.py 2>&1 | tail -3
uv run python scripts/check_ort_versions.py 2>&1 | tail -3
uv run python scripts/check_openjtalk_version_sync.py 2>&1 | tail -3
uv run python scripts/check_ruff_version_sync.py 2>&1 | tail -3
uv run python scripts/check_migration_changelog_parity.py 2>&1 | tail -3

drift があれば bump 前に修復するよう警告。

フェーズ 3: Bump diff の markdown 提示

--target-version を基準に、 該当 runtime の manifest 全てに対する diff を markdown 出力:

出力例 (markdown):

• Python (VERSION): <current> → <target-version>
• Rust (src/rust/Cargo.toml [workspace.package].version): <current> → <target-version>
• npm synth (src/wasm/openjtalk-web/package.json): <current> → <target-version>

all の場合は 9 manifest 全てを順次出力する。

フェーズ 4: Lockfile 再生成手順

# Python
uv lock --upgrade-package piper-plus
# Rust
(cd src/rust && cargo update -p piper-plus)
# npm synth
(cd src/wasm/openjtalk-web && npm install --package-lock-only)
# npm g2p
(cd src/wasm/g2p && npm install --package-lock-only)

--apply 時は順次実行、 そうでなければコマンドのみ表示。

フェーズ 5: Swift checksum 計算ガイド

Package.swift の checksum / g2pChecksum は tag commit に存在していなければならない (SwiftPM は tag の git ref の manifest を解決し、checksum 不一致なら artifact has changed checksum で fail。release-shared-lib.yml の release job も tag push 時に placeholder / 不一致を hard-fail させる)。よって tag push 前 に実施する (gh release download は release がまだ無いので使えない):

# 1. release-shared-lib.yml を tag 無しで workflow_dispatch 実行し artifact を生成
gh workflow run release-shared-lib.yml --ref dev
# 完了後、run の workflow artifact を取得 (release ではない)
gh run download <run-id> --name libpiper_plus-ios-xcframework
# g2pChecksum は g2pVersion が今回 tag と一致する時のみ取得・更新
gh run download <run-id> --name libpiper_plus_g2p-apple-xcframework

# 2. swift package compute-checksum (workflow artifact のファイル名は version 無し)
swift package compute-checksum libpiper_plus-ios.xcframework.zip
swift package compute-checksum libpiper_plus_g2p-apple.xcframework.zip   # g2pVersion == TARGET のみ

# 3. Package.swift の `let checksum` (synthesis) を更新。
#    `let g2pChecksum` は g2pVersion が今回 tag と一致する時のみ更新
#    (異なる場合 release-shared-lib.yml が g2p checksum 検証を自動 skip する)。

# 4. PR で dev に入れ、その commit に v<TARGET_VERSION> tag を push (フェーズ 7 の順序)

workflow_dispatch build と tag build は deterministic なので checksum は一致する。この手順は tag push の直前 (フェーズ 7)。 dry-run でも手順を出力する。

フェーズ 6: CHANGELOG 昇格 markdown diff

awk '/^## \[Unreleased\]/{flag=1; next} /^## /{flag=0} flag' CHANGELOG.md

を抽出し、 以下を提案:

## [<TARGET_VERSION>] - <YYYY-MM-DD>

(Unreleased から移動した内容)

## [Unreleased]

(空 or next-version 着手項目)

--apply で直接 Edit、 そうでなければ diff のみ出力。

フェーズ 7: Publish 順序ガイド

CONTRIBUTING.md の「Release order」「v<X.Y.Z> tag push の注意点」と各 release workflow の on: トリガーを正とする。 推奨順序:

1. タグなしで native / Apple 成果物を生成・検証: release-shared-lib.yml を workflow_dispatch (フェーズ 5)
2. Package.swift の版番号・URL・checksum を PR で更新 → merge と CI 確認 (この commit が以降すべてのタグの対象)
3. 必要な独立パッケージを公開 (既公開なら skip、 再 tag 不要):
   • npm: wasm-g2p-v<X.Y.Z> (g2p-wasm-ci.yml、 @piper-plus/g2p) の公開完了を待ってから npm-v<X.Y.Z> (npm-publish.yml、 piper-plus)。 逆順だと piper-plus の fresh install が notarget で失敗する
   • crates.io: rust-v<X.Y.Z> tag を push し、 その tag を選んで release-rust.yml を workflow_dispatch (piper-plus-g2p → piper-plus → piper-plus-cli の順に publish)
   • NuGet: csharp-v<X.Y.Z> tag を push し、 その tag を選んで release-csharp.yml を workflow_dispatch
   • PyPI (G2P): python-g2p-v<X.Y.Z> (g2p-python-ci.yml)
   • Maven Central: kotlin-g2p-v<X.Y.Z> (release-kotlin-g2p.yml)
4. Docker: 同じ検証済み commit に docker-v<X.Y.Z> を push → docker-build.yml が build・署名・公開 (<X.Y.Z> / latest)。 consumer 検証まで行う。 v<X.Y.Z> だけでは Docker は公開されない
5. v<X.Y.Z>: 同じ commit に push → release-shared-lib.yml (libpiper_plus + iOS/Android xcframework、 Package.swift checksum 検証) と sbom.yml が発火
6. PyPI (Python runtime): 同じ v<X.Y.Z> tag を選んで dev-create-release.yml (Manual Release) を workflow_dispatch (version 入力)。 PyPI へ公開し、 NuGet / crates.io は既存パッケージの検証のみ (ここでは publish しないので手順 3 を先に済ませる)

重要 (フェーズ 5 参照): Swift checksum 更新は v<X.Y.Z> tag の 前 (手順 2)。 placeholder のまま tag を push すると release-shared-lib.yml の release job が hard-fail し、 post-tag の後追い PR では SwiftPM 解決を救済できない (tag の git ref が解決対象のため)。

GitHub Release は dev-create-release.yml (draft + 自動 note) と release-shared-lib.yml (asset 添付) の 2 workflow から作られ、 どちらも CHANGELOG [X.Y.Z] 本文を使わない。 draft の本文を CHANGELOG [X.Y.Z] で手動置換してから publish する。

フェーズ 8: 公開後検証コマンド

# 各 registry で publish 完了を確認
curl -s https://pypi.org/pypi/piper-plus/json | jq -r '.info.version'
curl -s https://crates.io/api/v1/crates/piper-plus | jq -r '.crate.max_version'
npm view piper-plus version
npm view @piper-plus/g2p version
curl -s "https://api.nuget.org/v3-flatcontainer/piperplus.core/index.json" | jq -r '.versions[-1]'
curl -s "https://search.maven.org/solrsearch/select?q=g:io.github.ayutaz+AND+a:piper-plus-g2p-android&rows=1&wt=json" | jq -r '.response.docs[0].latestVersion'

target version と一致するまで sleep 30 で polling、 30 分以内に揃わなければエラー報告。

注意

• 既存 release-prep skill との関係: release-prep は「現状の version 散在確認」、 本 skill は「次回 version へ bump する適用案生成」。 先に release-prep で drift を解消してから本 skill を使う流れが推奨。
• memory feedback_merge_caution.md: tag push / publish に類する操作は本 skill では実行しない。 手順表示のみ。
• memory feedback_pr_no_milestones.md: マイルストーン番号付与しない。
• memory feedback_data_asset_distribution.md: data asset 追加時の 7 manifest 同時更新も本 skill では確認のみ。
• --dry-run がデフォルト で、 --apply は明示指定が必要。

使用例

# 全 runtime の次回リリース bump 案を生成 (dry-run)
/prepare-release all --target-version <target-version>

# Python だけ確定、 適用
/prepare-release python --target-version <target-version> --apply

# Rust の次回リリース、 lockfile 再生成手順のみ表示
/prepare-release rust --target-version <target-version>

期待効果

• リリース時の 9 manifest 同時 bump を 1 skill に集約 (現状: 手動 Read + Edit + Lock 再生成 + tag 順序記憶)
• npm tag 順序違反 (g2p 先行必須) を強制チェック
• Swift checksum 漏れ の防止 (release-shared-lib.yml で fail する前にガイド)
• CHANGELOG [Unreleased] 昇格 の規定化 (現状: 手動 markdown 編集)
• publish 後検証 の自動化 (target version が registry に届くまで polling)