---
name: patch-release-prep
description: Unity / VRChat package の patch リリース（バグ修正・軽微な改善）公開準備を一括で進めるオーケストレーション Skill。修正内容確認 → version bump → CHANGELOG → BOOTH_PACKAGE 文面更新（条件付き）→ sync-check → version 固定 → BOOTH zip 再作成（条件付き）までを Claude Code が実行し、GitHub Release / VPM listing / VCC / BOOTH 更新（条件付き）/ リリース管理 DB はせばんぬ手作業チェックリストとして出力する。patch リリース・パッチリリース・version bump・バグ修正リリース・軽微な修正リリース・bug fix release・修正版リリース・minor リリース・major リリース・マイナーリリース・メジャーリリース、などの合図で発動（発火キーワードの正本＝この description）。
---

# patch-release-prep

Unity / VRChat package の patch リリース（バグ修正・軽微な改善）公開準備をステップ 1〜8 + ゲート 2 段階で回すオーケストレーション Skill。
repo 構成 / release workflow / `source.json` 登録 / BOOTH 商品ページ作成は初回リリース時点で済んでいる前提で、差分に絞ったフローを実行する。
Claude Code がステップ 1〜8 を実行し、ステップ 9〜13（GitHub Release / VPM listing / VCC / BOOTH 更新 / リリース管理 DB）はせばんぬ手作業チェックリストとして出力する。

## When to use this skill

明示指示で発動する想定。

### 発火キーワード

発火キーワードの正本は frontmatter `description` の合図列挙（patch 系 + minor / major リリースを含む。明示指示で発動）。本 Skill は patch / minor / major リリースの正規ルーティング先（CLAUDE.md §10）。

### Claude から提案するタイミング

- バグ修正または軽微な改善の実装が完了した
- 依存 version を追従する必要が出た
- 公開済み版に影響する修正が commit された後

### 明示指示の指示テンプレ

せばんぬから Code への指示テンプレ（パラメータ確定用。本 Skill 発火時に Code が同等のパラメータを確認してもよい）:

```
patch-release-prep の SKILL.md を読んで、対象リポに対して patch リリース準備を実行してください。

- target_repo: {対象リポのパス}
- version: {patch 後の version（SemVer、v 無し。例: 1.0.1）}

計画のみ出してください。「進めてください」と返答するまで実装しないでください。
```

明示指示で発動する（auto-invoke 化の検討状況は `next-phase/cross.md` META-T19 管理）。

---

## 核心原則

共通軸（公開順 / URL・version・導線・同梱物 / 2 段階ゲート骨格 / version 表記 / owner 前提）は `skills/release-shared/COMMON.md` §A が正本（実行前に view 済み）。patch 固有の差分のみ:

- **2 段階ゲートの中身**: A = 修正内容承認 / B = sync-check 指摘解消方針
- **default branch は初回で決まったものを踏襲**
- **BOOTH 更新は条件付き**（必要時のみ）: VPM が主導線、BOOTH は補助導線。patch のたびに BOOTH を更新しない。判断は後述「BOOTH 更新の判断基準」に従う
- **前版との差分にフォーカス**: 全体棚卸しではなく、前 release tag からの差分を対象にする

---

## Inputs

| パラメータ | 必須 | 説明 |
|---|---|---|
| `target_repo` | 必須 | 対象リポのローカルパス |
| `version` | 必須 | patch 後の version（SemVer、`v` 無し。例: `1.0.1`） |

`displayName` / package name 等は対象リポの `package.json` から読む。
前 version は `git tag` または直近の GitHub Release から取得する。

---

## BOOTH 更新の判断基準

BOOTH 更新の要否は以下の基準で判断する（核心原則「BOOTH 更新は条件付き」を具体化）。

### 更新する

- ユーザーから見える機能追加・UI 変更がある
- BOOTH 商品説明文の「できること」「使い方」に影響する修正
- BOOTH_PACKAGE 内の導入手順やクイックスタートが変わる修正
- UI 変更で使い方ガイド（HTML）の説明・スクショが古くなる修正

### 更新しない

- 内部バグ修正で使い方が変わらない
- エラーメッセージ改善やログ修正
- 依存 version の追従だけ

> [!note] 両リストに掛かる修正に注意
> 上の「更新しない」項目でも、**同じ修正が「更新する」側の条件（UI 変更でスクショが古くなる 等）も同時に満たす**ことがある（例: エラーメッセージ改善がダイアログ UI 文言変更を伴う）。その場合は「更新する」側が勝つ。「更新しない」リストの字面だけで早合点せず、後段「判断基準（迷いやすいポイント）3」で突き合わせる。

**判断の境界線**: 「BOOTH の商品説明文や同梱テキストを書き換える理由があるかどうか」。

### 「更新する」と判断した場合に実行するステップ

> [!warning] 分岐（BOOTH 更新可否）— 本 Skill の条件分岐の正本
> - **「更新する」** → ステップ 4・8・12 を実行する
> - **「更新しない」** → ステップ 4・8・12 をスキップする
>
> 各ステップ冒頭の分岐表示が実行時ガード。

---

## Workflow

**実行前に必須**: `skills/release-shared/COMMON.md` を view する（公開定型の共通正本 §A〜§I・§B は欠番。本 Skill 本文は patch 固有の差分のみ）。

ステップ 1〜8 を Claude Code が実行する。ステップ 9〜13 はせばんぬ手作業（後述「Handoff Checklist」）。

ステップの共通 / 条件付きの区別:

- **毎回実行**: ステップ 1〜3・5〜7（+ ゲート A / B）、Handoff のステップ 9〜11・13
- **条件付き（BOOTH 更新「する」場合のみ）**: ステップ 4・8・12（分岐の正本 = 前述「BOOTH 更新の判断基準」）

### ステップ 1: 修正内容の確認

前回 release から今回の patch までの変更内容を棚卸しする。

（CLAUDE.md §10 の「棚卸し=コード面の網羅確認」は初回リリース時の全体走査を指す。patch では前 release tag からの差分にスコープを絞る。）

確認コマンド:

- `git log <prev-tag>..HEAD --oneline` — commit 一覧
- `git diff <prev-tag>..HEAD` — 変更差分

観点:

- 修正された内容の分類（バグ fix / 軽微な改善 / 依存追従 / UI 変更 等）
- ユーザーから見える変更の有無（UI 変更・機能追加・説明文への影響）
- CHANGELOG に書くべき項目の洗い出し
- 依存 version 変更の有無
- BOOTH 更新要否の初期判断（「BOOTH 更新の判断基準」参照）

出力:

- 変更 commit 一覧 + 要約
- BOOTH 更新要否の初期判断（更新する / 更新しない / 判断保留）
- CHANGELOG に追加する項目の案

### 【ゲート A】 修正内容承認

修正内容の確認結果と BOOTH 更新要否の初期判断を提示し、せばんぬの承認を得る。承認前にステップ 2 以降に進まない。

### ステップ 2: version bump（package.json）

`package.json` の `version` を patch 後の値（Inputs `version` 指定値）に更新する。

SemVer: `v` 無し。例: `1.0.0` → `1.0.1`。

### ステップ 3: CHANGELOG 追記

ステップ 1 で洗い出した項目を CHANGELOG に追記する。

- 見出しは新 version に合わせる（例: `## 1.0.1`）
- 初回リリース時の形式と揃える（Added / Changed / Fixed / Notes 等）
- 依存 version 追従のみの patch は `Changed: dependency bump` のように簡潔に書く

### ステップ 4: BOOTH_PACKAGE 文面更新（条件付き）

> [!warning] 分岐（BOOTH 更新の判断基準）
> - **「更新する」** → 本ステップを実行
> - **「更新しない」** → このステップをスキップし、ステップ 5 に進む

更新対象:

- **`BOOTH_PACKAGE/` 内の各ファイルで version 記載がある箇所**（「更新する」分岐では version 表記同期は本ステップの担当。ステップ 5 の sync-check 検出に委ねない — ステップ 4/5 境界の見落とし注意）
- 機能追加・UI 変更に伴う説明文の更新（必要に応じて）
- HTML 使い方ガイドを持つリポでは、UI 変更時に `03_使い方ガイド.html` の改訂要否も判断する（手順は [[USER_DOC_HTML_GUIDELINES]] 参照）

文面方針は `skills/release-shared/COMMON.md` §F が正本（実行前に view 済み）。

### ステップ 5: sync-check 実行

既存の [[skills/public-release-sync-check/SKILL]] を呼び出す。実行コマンド・出力分類 = `skills/release-shared/COMMON.md` §C が正本。

**ステップ 4 で「BOOTH 更新しない」判断だった場合**は `--booth-not-updated` を付ける（`version.booth-package.mismatch` が Warning に降格される — BOOTH 非更新 patch では BOOTH_PACKAGE の version 不一致が想定内のため。OPT-T80 実装 2026-07-04）。

### 【ゲート B】 sync-check 指摘解消方針承認

sync-check レポートと修正計画を提示し、せばんぬの承認を得る。承認前にステップ 6 以降に進まない。

### ステップ 6: sync-check 指摘解消 + commit

ゲート B で承認された修正計画に従い、Blocking / Warning を解消する。

commit: ドキュメント（CHANGELOG / BOOTH_PACKAGE 文面）と sync-check 解消分をまとめて 1 commit にする（`package.json` の version bump は除く、ステップ 7 で単独 commit）。

**commit prefix の考え方:**

- `docs`: CHANGELOG / BOOTH_PACKAGE / 公開導線
- `ci`: workflow（patch では通常変更なし）
- `chore`: 依存追従、版間調整

### ステップ 7: version 整合チェック + bump commit + push

`package.json` / `CHANGELOG` / `BOOTH_PACKAGE`（更新した場合）内の version が全て新 version に揃っているか確認する。

BOOTH 非更新 patch では BOOTH_PACKAGE の version は据え置きとなり、ステップ 5 の sync-check 上は `Warning` 扱い（spec 例外。「patch のたびに BOOTH を更新しない」核心原則と整合）。BOOTH_PACKAGE を更新する patch では従来どおり新 version に揃える。

commit: `package.json` の version bump を単独で commit + push する（他の変更と混ぜない）。

### ステップ 8: BOOTH zip 再作成（条件付き）

> [!warning] 分岐（BOOTH 更新の判断基準）
> - **「更新する」** → 本ステップを実行
> - **「更新しない」** → このステップをスキップし、「公開前チェック」に進む

更新後の `BOOTH_PACKAGE/` から BOOTH 配布 zip を再作成する。zip 規約（出力先 / サブフォルダ分離 / 展開直下 / `.meta` 除外）は `skills/release-shared/COMMON.md` §D が正本。patch 固有: 前 version の zip は残す（上書きしない・過去 version を積む）。

---

## 公開前チェック（Handoff 前の最終確認）

ステップ 8 完了後（**BOOTH 更新「しない」場合はステップ 7 完了後**）、ステップ 9 に進む前に以下を確認する。

### repo 内（Claude Code が横断確認）

対象ファイル:

- CHANGELOG
- `package.json`
- BOOTH_PACKAGE（**BOOTH 更新「する」場合のみ**）

確認観点: 共通観点は `skills/release-shared/COMMON.md` §I が正本（BOOTH_PACKAGE⇔README 観点は BOOTH 更新「する」場合のみ適用）。

- `package.json` / CHANGELOG / BOOTH_PACKAGE の version が全て新 version で揃っているか
- VCC 用 URL が `index.json` になっているか（通常は変更なし）
- listing page と `index.json` の役割が混ざっていないか

### repo 外（せばんぬが確認）

- **BOOTH 更新「する」場合のみ**: BOOTH 商品本文 / 商品画像 / 告知文 / SNS 固定文 / 下書きメモ

---

## Handoff Checklist（せばんぬ手作業）

ステップ 9〜13 はせばんぬの手作業。Claude Code はこのチェックリストを出力して終了する。

### ステップ 9: GitHub Release（共通）

`skills/release-shared/COMMON.md` §E が正本（実行前に view 済み）。

### ステップ 10: VPM listing 更新

```
- [ ] listing repo の GitHub Actions workflow_dispatch で再ビルド（patch では通常これが主経路）
- [ ] または listing repo に push（source.json 変更がある場合のみ。patch では通常なし）
- [ ] Pages で新 version が反映されているか確認
- [ ] listing repo 側の走査: `source.json` の `githubRepos` + README の package リスト
```

**listing 更新フロー補足**: package repo は初回リリース時に `source.json` の `githubRepos` に登録済み。新 version は GitHub Release の asset zip から自動取得されるので、listing repo への commit は通常不要で、再ビルド（workflow_dispatch）のみが主経路。

**トラブルシュート**: listing に package が出ない時の切り分けは初回リリース時と共通（[[skills/initial-release-prep/SKILL]] ステップ 10「トラブルシュート」参照）。

### ステップ 11: VCC 確認

```
- [ ] VCC で新 version が表示されるか確認
- [ ] VCC からインストール or 更新できるか確認
```

**VCC cache の注意**: 同 major.minor の patch bump では VCC が cache を使い続ける場合がある。新 version が見えない時の切り分け手順は特殊ケース「VCC cache の事情」を参照。

### ステップ 12: BOOTH 更新（条件付き）

> [!warning] 分岐（BOOTH 更新の判断基準）
> - **「更新する」** → 本ステップを実行
> - **「更新しない」** → このステップをスキップし、ステップ 13 に進む

```
- [ ] BOOTH zip アップロード（`Releases/booth/{ToolName}/` にある新 version の zip）
- [ ] 商品ページの更新履歴に追記
- [ ] 必要に応じて商品説明文を更新（下記「BOOTH 商品説明文の基本形」参照）
```

### ステップ 13: リリース管理 DB 更新（必須）

`skills/release-shared/COMMON.md` §E が正本（実行前に view 済み）。

---

## BOOTH 商品説明文の基本形

BOOTH 更新時（ステップ 12）に参照する。基本構成・書き方の方針は `skills/release-shared/COMMON.md` §G が正本（実行前に view 済み）。

patch 固有: 更新は「更新履歴」追記と「できること」「使い方」への影響範囲の反映が中心。全文書き換えは避ける。

---

## リリース後の振り返り観点

共通軸は `skills/release-shared/COMMON.md` §H が正本（実行前に view 済み）。patch 固有: BOOTH 更新の判断は適切だったか（更新しなかった場合、ユーザー影響はなかったか）

---

## 特殊ケース

### MA 必須ツール / MA 対応ツール / MA 不使用ツール

初回リリース時に決めた MA タグ（「ModularAvatar設定済み」/「ModularAvatar対応」/ タグなし）は、通常 patch では変更しない。

ただし、patch で MA 依存の有無が変わる場合（例: MA 対応を追加 or 削除）は、商品ページのタグ・ロゴも追従する。この場合は BOOTH 更新「更新する」扱い。

### 依存 version 追従のみの patch

- sync-check で `vpmDependencies` の変更のみが検出される
- 判断: BOOTH 非更新の典型（→「BOOTH 更新の判断基準」）/ CHANGELOG: `Changed: dependency bump`（→ステップ 3）/ **ステップ 4・8・12 はスキップ**

### VCC cache の事情

同 major.minor 内の patch bump では VCC が listing cache を使い続ける傾向がある。公開直後に VCC で新 version が見えない場合は、必ずしも公開失敗ではないので以下の順で切り分ける:

1. Pages で listing `index.json` を直接確認（新 version が入っているか）
2. VCC 再起動
3. listing repo の workflow_dispatch で再ビルド
4. それでも反映されない場合は listing の `source.json` / `githubRepos` 設定を確認

### default branch が main 以外の場合

default branch の扱いは核心原則を参照（初回リリース時に決めたものを踏襲し、通常 patch では変えない）。

---

## やりがちな失敗（Claude 自身向け）

- VCC cache で新 version が反映されない状態を「公開失敗」と判断してしまう
  → 切り分けは特殊ケース「VCC cache の事情」参照（Pages で `index.json` を直接確認し、新 version が入っていれば公開は成功）
- ステップ 9〜13（`gh release create` / listing 再ビルド / BOOTH 公開）を「チェックリストを消化してあげる」つもりで代行実行する
  → 全て不可逆の外向き操作でせばんぬ手作業（Boundaries）。Code は Handoff Checklist の出力まで
- `--booth-not-updated` を「Warning を黙らせる」目的で付ける
  → 検査を自分で緩める操作。付けてよいのは「BOOTH 更新の判断基準」で「更新しない」と**確定**した場合のみ

※ 実運用で蓄積した失敗パターンはここに追記する。

---

## 判断基準（迷いやすいポイント）と作業後セルフチェック

> 2026-07-05 Wave 2（Sonnet/Opus 移行整備）で追加。

### 判断基準

**1. BOOTH 更新可否の判断が「保留」のままステップ 5 に来た場合**
- `--booth-not-updated` は**付けない**（安全側 = 不一致を Blocking のまま出し、ゲート B でせばんぬと決める）。フラグは「更新しない」確定後のみ。

**2. 前 version（prev-tag）の特定**
- 前 version = **直近の GitHub Release の tag**（公開済みの実績が正）。`git tag` に Release 未作成の tag が余っていたら中途状態なので、無言でどちらかを採用せず止めて確認する（採用を誤ると CHANGELOG の対象 commit が漏れる/重複する）。

**3. 「更新しない」リストと「更新する」リストの両方に掛かる修正**
- 例: エラーメッセージ改善（更新しない側）がダイアログ UI の文言変更を伴い使い方ガイドのスクショが古くなる（更新する側）→ **「更新する」側が勝つ**。境界線はあくまで「BOOTH の商品説明文・同梱テキスト・ガイドを書き換える理由があるか」。

**4. minor / major で全体走査を足すか**
- 差分フォーカスのまま流してよいのは「README / TOOL_INFO / 商品説明の記述が前版のまま正しい」場合。機能追加で「できること」が変わる minor/major は、ステップ 1 に initial-release-prep ステップ 2 相当の公開文書横断確認を足す。

### 作業後セルフチェック（Handoff Checklist 出力前に全項実施）

- [ ] sync-check 実行（実行コマンド・出力分類 = `skills/release-shared/COMMON.md` §C が正本）→ Blocking 0。`--booth-not-updated` の付与は判断基準 1 に適合
- [ ] version 3 面一致: `grep -rn "<version>" <repo>/package.json <repo>/CHANGELOG*` + BOOTH_PACKAGE（更新した場合）が全て新 version
- [ ] zip 検証（ステップ 8 実行時）: zip 一覧で `BOOTH_PACKAGE/` フォルダ自体が含まれず展開直下にファイルが見える / `.meta` 混入なし / 前 version の zip が残っている（上書きしていない）
- [ ] commit 分離: version bump が単独 commit / 他変更（docs）と混ざっていない（`git log --oneline -5` + `git show --stat` で確認）
- [ ] push はステップ 7 の bump commit のみ（それ以外の push・`gh release create` を実行していない）
- [ ] Handoff Checklist をステップ 9〜13 全項で出力した（BOOTH 非更新ならステップ 12 はスキップ明示）

---

## Boundaries

### やること

- patch リリースの公開準備（ステップ 1〜8）
- 既存 `public-release-sync-check` Skill の呼び出し（ステップ 5）
- 各ステップの実行結果レポート
- BOOTH 更新要否の判断支援
- 公開前チェック（Claude Code 側）の実施
- Handoff Checklist（ステップ 9〜13）の出力

### やらないこと

- 初回リリース（別フロー。`initial-release-prep` Skill に委ねる）
- 修正の実装・テスト（Skill 発動前に完了している前提）
- GitHub Release の作成・asset 確認（せばんぬ手作業）
- listing repo の更新・走査（せばんぬ手作業）
- VCC の実機確認（せばんぬ手作業）
- BOOTH 商品ページの更新公開（せばんぬ手作業）
- sync-check のルール変更や拡張
- repo 固有の例外ルールの Skill への取り込み（CLAUDE.md に逃がす）

### minor / major bump の扱い

本 Skill は patch bump（`1.0.0` → `1.0.1`）を想定しているが、minor bump（`1.0.0` → `1.1.0`）/ major bump（`1.0.0` → `2.0.0`）でも同じフロー（既存 repo 構成 / workflow / `source.json` 登録を前提に bump）で流用可能。BOOTH 更新の判断基準は SemVer の段階に関係なく同じ（ユーザーから見える変更があるか）で適用する。

---

## References

- [[skills/release-shared/COMMON]] — 公開定型ブロックの単一正本（実行前に view 必須。§A〜§I・§B 指示テンプレは廃止 — 各 Skill 本文が正本）
- [[skills/initial-release-prep/SKILL]] — 姉妹 Skill。初回リリース準備。構造・トーンを揃える参照元
- [[skills/public-release-sync-check/SKILL]] — ステップ 5 で呼び出す既存 Skill
- [[skills/closeout-flow/SKILL]] — リリース後の closeout で使用
- [[USER_DOC_HTML_GUIDELINES]] — BOOTH_PACKAGE 同梱の HTML 使い方ガイドを持つリポでの改訂判断・zip 再作成タイミング
- [[PUBLIC_RELEASE_GUIDELINES]] — 公開順・切り分けルール等の上位方針（層3 view 義務対象）。公開順は本 Skill 核心原則に移植済み。切り分けルール（repo 固有 / 全 repo 共通 / repo 外手修正）は本 Skill 未移植のため、適用時は本ガイドを view する