---
name: vava
description: リポジトリの次バージョンを1回だけ決定し、version 同期、利用者向け README・CHANGELOG の最小更新、検証、リポジトリ規約に従う commit、main push、release/x.y.z ブランチ作成、既存の署名またはCI release 完走、明示設定済み参照元の更新、マージ済み旧 release ブランチ整理まで一気に行うリリースワークフロー。Use when the user runs /vava, asks to bump or publish the next version, create a release branch, or start a release. Supports .NET/Velopack, Node/extensions, Rust, Python, Flutter, and Xcode/App Store projects.
---

# /vava — 次バージョンをリリースする 💖

この Skill の明示呼び出しは、対象リリースに必要な version 更新、**source repository の作業ツリーに残っている全ての変更（他セッションで作られたものを含む）の commit**、main push、`release/<version>` push、source repository の既存 release 経路の実行、`vava.config.json.consumerUpdates.targets` に明示された参照元の参照更新・検証・default branch への commit / push、マージ済み旧 release ブランチ整理を許可する。force push、履歴改変、未マージブランチ削除、別 version の発行、参照元製品自体の version bump / release / deploy は含まない。

変更範囲は version 同期、利用者向け文書、既存 release 経路の完走、明示設定済み参照元における今回公開物の参照と lock / 同梱コピーの同期に限定する。それ以外の依存更新、bot PR の merge、製品仕様、配信基盤は別依頼として扱う。

応答と commit message は、対象リポジトリとユーザーの言語・文体指定に従う。ブランチ名は常に `release/<major>.<minor>.<patch>` 形式。ローカルの build、test、lint、typecheck、package、署名、publish precheck は、同じ作業ツリーや出力先で競合しないよう**常に直列実行**し、各コマンドの終了を確認してから次へ進む。並列 tool call、background job、複数 shell による同時実行は使わない。長時間処理は**そのセッションで公開されている継続機構**を使って 1 プロセスだけ実行する。Codex で shell 実行が cell ID を返した場合は同じ cell を `wait` で再開し、同じ release command を二重起動しない。CI は対象 run ごとに `gh run watch <run-id> --compact --exit-status` を使う。Windows のコマンド例は PowerShell を正本とする。自然言語の wakeup で `/vava` を再起動せず、継続時は既存状態を再取得して未完了 checkpoint から進める（詳細は [CI recovery](references/ci-recovery.md)）。

## 🌙 dry-run

`--dry-run` または「計画だけ」「プランだけ見せて」では、リポジトリ、現在差分（同梱予定の既存未コミット変更を含む）、version、更新予定、検証、Git 操作、release 経路、参照元ごとの更新コマンド・許可 path・検証・push 予定、cleanup 候補を読み取り専用で示して終了する。参照元候補を探索しても更新対象に昇格させず、`offline` 併用時は remote・CI・store・公開物を照会せず、live 未確認と明記する。

## 1. preflight 🔍

1. 適用指示、source repository の Git root を `SOURCE_GIT_ROOT`、push 対象 remote を `SOURCE_REMOTE` として固定し、remote URL、default branch、現在ブランチ、status、remote 差分を確認する。
2. 未コミット変更（未追跡ファイルを含む）を全て読み、内容を把握する。**このセッションで作った変更かどうかで選り分けない。**別セッション・別作業由来の変更も、今回の release に同梱して commit / push する対象に含める。除外してよいのは §3 の秘密・証明書・一時成果物と、`.gitignore` 済みファイルだけ。分離は行わないので、分離可否の確認も不要。
3. project type、既存 release script/workflow、署名、store integration、`vava.config.json`、CHANGELOG の有無を確認する。`consumerUpdates.targets` があれば[参照元更新](references/consumer-updates.md)を読み、対象・公開確認・許可 path・更新・検証コマンドを mutation 前に固定する。設定が無い場合は候補を読み取り専用で報告してもよいが、参照元は変更しない。
4. live 実行では `git -C <SOURCE_GIT_ROOT> fetch <SOURCE_REMOTE> --prune` 後、PRIMARY version の working tree 値と `HEAD` 値、CHANGELOG、local/remote の `release/<version>`、tag、release workflow の branch/head SHA、成果物、store、配信先を照合し、`RELEASE_MODE=new|resume` を固定する。dry-run では local ref を変更せず、`git -C <SOURCE_GIT_ROOT> ls-remote <SOURCE_REMOTE>` と API の読み取り結果で remote 状態を照合する。
   - working tree の PRIMARY が `HEAD` より新しく、その version に対応する文書差分がある場合は、作成途中の version として `resume` にする。`OLD_VERSION` は `HEAD` の値、`NEW_VERSION` は working tree の値を使う。
   - 現在 version の local/remote release branch または外部 release 状態が存在し、必要な checkpoint が未完了なら `resume` にする。`NEW_VERSION` は現在 version のままにする。
   - version commit、release branch、workflow、成果物、store、対象デプロイ、設定済み参照元更新がすべて完了している場合だけ、次の新規 patch release を `new` にする。`consumerUpdates.targets` があれば、mode 固定前に現在 version を候補 `NEW_VERSION` として[参照元更新](references/consumer-updates.md)の公開確認と再開分類を読み取り専用で実行する。1 件でも `pending` / `blocked` なら同じ version の `resume` とし、source package / binary / store submit を再実行しない。全 target が `complete` / `already-current` と一意に確認できた場合だけ `new` を許可する。
   - 外部状態を一意に照合できない場合は mutation 前に停止し、未確定の branch、SHA、run、artifact、store/deploy 状態を列挙する。利用者の選択で結果が変わる場合だけ、1 つの具体的な質問を行う。
5. project 固有 precheck（`localRelease.precheck` 等）があれば version 変更前に実行する。非 0 なら即停止。
6. `RELEASE_MODE=new` の場合だけ直近タグから HEAD までの差分を確認する。コード・文書・設定のどれも変わっていない場合は version を上げず、差分が無い事実と直近タグを示して終了する。`RELEASE_MODE=resume` は未完了 checkpoint の有無で続行を判断する。

## 2. version を1回だけ決める 🔢

[version ファイル規則](references/version-files.md)を読み、PRIMARY と同期対象を確定する。

- repo 固有規則または明示指定があれば従う。
- 通常の SemVer は patch を 1 つ上げる。
- prerelease、複数の独立 version、互換性のない独自形式で一意に決められない場合だけ確認する。

`RELEASE_MODE=new` では `OLD_VERSION` から patch を 1 回だけ進める。`RELEASE_MODE=resume` では検出済みの `NEW_VERSION` を保持し、version を再度上げず、CHANGELOG 節や release commit を重複作成しない。どちらも `OLD_VERSION`、`NEW_VERSION`、対象ファイルを固定し、途中で再計算しない。CI 失敗などどんな理由でも別 version へ切り替えず、完了済み checkpoint を飛ばして最初の未完了 checkpoint から再開する。

## 3. version と利用者向け文書を更新する ✏️

- version field だけを限定して更新し、依存 version や lockfile へ波及させない。
- README に現 version の利用者向け表記（badge・URL・見出し）がある場合だけ更新する。新規作成はしない。
- CHANGELOG（`CHANGELOG.md` 等）がある場合は[CHANGELOG 更新規則](references/changelog.md)を読み、既存書式のまま `NEW_VERSION` の節を追加する。`RELEASE_MODE=resume` では既存節を検証して保持し、不足または不整合のある箇所だけ補正する。無いリポジトリでは作らず、未整備として報告する。
- 秘密、証明書、一時成果物が Git 対象に入っていないことを確認する（`.env` / `*.pem` / `*.key` / `*.pfx` / `secrets.json` 等は絶対に stage しない）。

## 4. 検証する 🧪

リポジトリの既存コマンドと CI 条件を正本に、build、test、lint、typecheck、package/publish precheck を必要な範囲で実行する。**複数の検証コマンドを並列起動しない。**test や package が内部で build を呼ぶ場合も含め、先行コマンドとその子プロセスが終了したことを確認してから次のコマンドを開始する。リポジトリ固有コマンドが自ら複数の build process を同時起動する場合は、その既存の直列オプションまたは直列相当の個別コマンドを使う。失敗を skip や `--no-verify` で隠さず、今回範囲の原因は修正して同じ検証を再実行する。

store / marketplace へ提出する project は、**最初の `release/<NEW_VERSION>` push より前**に [release integration](references/release-integrations.md) の「Store 提出前の入力凍結」を完了する。不足を見つけたら release branch を作らず §3・§4 へ戻す。Chrome Web Store を含む store 固有の停止条件と手動 checkpoint の扱いも同 reference を正本とする。

## 5. commit、push、release ブランチ 🚀

1. **作業ツリーの変更を残さず commit する。**§1-2 で把握した既存の未コミット変更（他セッション由来・未追跡ファイルを含む）を、主題ごとの commit に分けて先に作る。stage は主題単位で明示的に行い、都度 cached diff と `git diff --cached --check` を確認する。秘密・証明書・一時成果物（`.env` / `*.pem` / `*.key` / `*.pfx` / `secrets.json` 等）が cached diff に現れたら unstage し、`.gitignore` への追加要否を報告に含める。
2. version 更新分を stage して、リポジトリ規約に従う release commit（例: `v<NEW_VERSION> リリース`、コード変更を含む場合は要約付き）を作り、1 の commit とまとめて固定済み `SOURCE_REMOTE` の default branch へ push する。複数行 message は PowerShell の here-string を一時 message file に保存して `git commit -F <file>` へ渡し、commit 後に一時 file を除去する。push 後に `git -C <SOURCE_GIT_ROOT> status --porcelain` が**空**であることを確認する（秘密ファイル以外が残っていたら commit 漏れとして扱い、追加 commit して push し直す）。`RELEASE_MODE=resume` で同じ version の release commit が既にある場合は重複 commit を作らない。
3. release ブランチを作る直前に、提出前入力凍結の結果、`git -C <SOURCE_GIT_ROOT> status --porcelain` が空、default branch の `HEAD` と `<SOURCE_REMOTE>/<MAIN_BRANCH>` が一致することを再確認し、その SHA を `RELEASE_HEAD_SHA` として固定する。ここで必要な修正を発見したら release ブランチを作らず §3・§4 へ戻り、default branch へ含めてから再度固定する。
4. `release/<NEW_VERSION>` が local/remote とも存在しない場合は、`RELEASE_HEAD_SHA` からブランチを **作成だけ**して（`git -C <SOURCE_GIT_ROOT> branch release/<NEW_VERSION> <RELEASE_HEAD_SHA>`）、`git -C <SOURCE_GIT_ROOT> push -u <SOURCE_REMOTE> release/<NEW_VERSION>` で upstream を設定して push する。既存 branch が意図した release SHA と一致すれば作成・push を飛ばす。異なる場合は、[CI recovery](references/ci-recovery.md) の安全な fast-forward 条件と外部提出の再実行条件を両方満たす確認済み復旧だけを許可し、それ以外は上書きせず停止する。

**release ブランチへは checkout しない。**`git checkout -b` / `git switch -c` は作成と同時に HEAD を移すため、作業ブランチが release ブランチのまま残る。その状態で以降の変更を commit すると、default branch ではなく release ブランチへ載り、`push: branches: release/**` 型の workflow を同 version で再発火させる（AMO / CWS は同 version の重複提出を拒否するため復旧が面倒になる）。release ブランチは push 先として作るだけで、作業は常に default branch で続ける。

未コミット変更を「無関係だから」という理由で残さない。ゆろちは複数セッションを並行して回すため、`/vava` 時点の作業ツリーには別セッションの成果が残っている前提で動く。pre-commit hook が失敗したら停止して原因を報告する。

## 6. release を完走する 🎯

source project の既存方式を使う。この節で許可する production deploy は source release に一意に結び付いた経路だけで、参照元 target の production deploy は §7 と[参照元更新](references/consumer-updates.md)に従い常に対象外とする。

- ローカル署名（SimplySign スマホ承認・lock drift 処理を含む）、CI、ハイブリッドの区別と詳細、Apple / AMO / CWS / Cloudflare の各手順は[release integration](references/release-integrations.md)を該当時だけ読む。
- 長時間 release は現在の runtime が公開する継続可能な shell 実行を 1 本だけ開始し、同じ execution cell または process を完了まで追跡する。途中中断時は成果物、process、署名、公開状態を調べてから再実行可否を判断する。
- CI が発火したら[CI recovery](references/ci-recovery.md)に従い、run を特定して完走を確認する。失敗時は同 version・同ブランチで復旧し、別 version の選択肢は提示しない。
- Apple、AMO、CWS、Cloudflare は project 設定と既存 workflow に含まれるものだけ扱う。
- release とデプロイの結び付きが次のいずれかで一意に確認できた場合だけ、その既存デプロイ経路を実行する: release workflow/script から deploy が呼ばれる、`vava.config.json` が production deploy を明示する、対象リポジトリの指示が release と正確な本番 target を対応付ける、または version/成果物を入力とする production 経路が 1 つだけ存在する。`deploy*` / `publish*`、`wrangler.toml` / `wrangler.json` / `wrangler.jsonc`、Cloudflare Pages / Workers、GitHub Pages、CI deploy job の存在だけでは候補検出に留め、実行根拠にはしない。
- デプロイ前に新 version 表記・ダウンロード URL 等の release 連動箇所を更新し、既存のデプロイ script / workflow をそのまま使う。デプロイ経路が未整備の場合だけ実行せず、必要な整備内容を報告に含める。
- `/vava` の明示呼び出しは、一意に結び付いた既存 production deploy の実行までを許可に含む。候補が複数ある、preview/staging/production を識別できない、または対象 account/project/zone が一意でない場合は外部書き込み前に停止し、候補と根拠を示して target を 1 つだけ確認する。新規デプロイ経路構築、DNS 変更、基盤の作成・削除は実行せず、必要な整備として報告する。
- 規定を根拠にデプロイを見送るときは、該当ファイルを検索してパスと行を引用する。明示的な結び付きが見つからない場合は「release 連動を確認できない候補」として報告し、推測で外部書き込みを行わない。
- デプロイ後は [release integration](references/release-integrations.md) の該当手順で配信中の実物とローカル成果物を照合し、一致を確認できるまで成功と報告しない。Cloudflare の purge 条件・対象範囲・再検証は同 reference を唯一の手順正本とする。

## 7. 参照元を更新する 🔗

`vava.config.json.consumerUpdates.targets` がある場合だけ、source release の成果物・store・配信物が `NEW_VERSION` として取得できることを確認した後に[参照元更新](references/consumer-updates.md)へ進む。対象は設定順に直列処理し、参照・lock file・同梱コピーだけを更新して各参照元の既存検証を通し、リポジトリ規約に従う commit を default branch へ通常 push する。参照元の version、release branch、公開・deploy は変更しない。参照元処理中も `SOURCE_GIT_ROOT` を保持し、全 target の処理後に同 root を再確認してから §8 へ進む。

source release 完了後の参照元失敗は source を巻き戻さず、成功・既に最新・保留を対象ごとに記録する。再実行では同じ `NEW_VERSION` と公開済み成果物を保持し、未完了の参照元 checkpoint だけを再開する。

## 8. 古い release ブランチを整理する 🗑️

この節の対象は source repository と固定済み `SOURCE_REMOTE` だけとし、全 Git 操作を `git -C <SOURCE_GIT_ROOT> ...` で実行する。ambient CWD、最後に処理した参照元、未固定の remote 名を操作対象の根拠にしない。

新ブランチ `release/<NEW_VERSION>`、未来 version、非 SemVer、default branch を保持する。古いブランチは **local / remote それぞれ独立に**（remote 削除済みで local に残る orphan も含めて）default branch へマージ済みと確認できたものだけ通常削除する。マージ確認の ref は実在する側に合わせる（local 削除は local ref、remote 削除は remote ref）。未マージブランチは固有 commit を示して保持し、削除には現在の会話で対象 branch を示した明示確認を得る。最後に local / remote 両方の一覧を照合する。

## 9. 報告する 📋

報告の前に **`git -C <SOURCE_GIT_ROOT> branch --show-current` で source repository の作業ブランチが default branch であることを必ず確認する**。release ブランチや detached HEAD に居たら、未コミット変更を保持したまま `git -C <SOURCE_GIT_ROOT> checkout <default branch>` で戻してから報告する（未コミット変更はブランチに属さないので、同一 commit 同士なら切り替えでそのまま持ち越せる）。戻れない事情がある場合は、現在ブランチと理由を報告の冒頭に書く。

報告の前に **`git -C <SOURCE_GIT_ROOT> status --porcelain` が空であることを確認する**。残っている変更は発生時点と配布物への影響で分類し、提出前後の扱いは [release integration](references/release-integrations.md) の入力凍結、package / binary / submission workflow の再実行は [CI recovery](references/ci-recovery.md) の復旧条件を正本にする。release 検証後に別セッション等から増えた変更は、未検証のまま追加 commit して完走扱いにしない。秘密・証明書・一時成果物だけは残してよく、その場合は何をなぜ残したかを報告に書く。

報告には**デプロイ状態を必ず 1 行含める**（`実行済み（対象と結果）` / `release 連動経路が無いため非該当` / `未整備のため保留＋必要な整備` / `候補を一意に決められず停止（候補と必要な確認）`）。release 連動経路があるのに実行していない状態で「完走」と報告しない。

ユーザーの言語・文体指定に従い、起点ブランチ、**報告時点の作業ブランチ**、`OLD_VERSION → NEW_VERSION`、更新ファイル（primary / secondary）、検証、commit SHA、push、release ブランチ、署名/CI/store 結果、デプロイ状態、参照元ごとの旧参照→新参照・commit・push・検証・保留理由、削除・保持ブランチ、未完了項目と安全な再開手順をまとめる。project type に応じた動作確認チェックリスト（拡張の読み込み確認、配信 URL の HTTP 200、TestFlight 反映等）を添える。