プラグインをリリースする手順

おさらい：リリースとは、マージ済みのプルリクエスト、タグ、GitHub リリースの3つです。

例では、次のリリースを 1.9.0、前回を 1.8.1 としています。番号は自分のものに置き換えてください。リリース作業には専用の worktree を使い、リポジトリが無視するフォルダに置きます。

• Node 18 以降 node --version で v18 以上が表示されます。
• Git と、変更のない maingit status --short で何も表示されません。
• GitHub CLI（ログイン済み）gh auth status で自分のアカウント名が表示されます。
• Claude Codeclaude --version でバージョンが表示されます。

つまり： 4つのツールを、1コマンドずつ確認します。結果が違うものは、手順1の前に直しておきます。

この章のポイント：最初に4つのツールを確認し、バージョン番号は自分のものに置き換えます。

おさらい： 4つのツールが使え、main に変更はありません。

1. 専用の worktree で、リリースブランチを作る。

   git worktree add .claude/worktrees/release-1.9.0 -b release/1.9.0 main
   cd .claude/worktrees/release-1.9.0

   確認： git worktree list で、新しいフォルダが [release/1.9.0] 付きで表示されます。

   うまくいかないとき：ブランチがすでにある場合は、-b release/1.9.0 main を外し、末尾にそのブランチ名を書きます。

2. マニフェストとテンプレートのバージョンを書き換える。

   sed -i 's/1\.8\.1/1.9.0/' .claude-plugin/plugin.json skills/glance-explainer/assets/template.html

   確認： git diff --stat で、2つのファイルのどちらも 2 +- と表示されます。

   うまくいかないとき：それ以外の数字なら、想定外の箇所に一致しています。元に戻し、2か所の番号を手で書き換えてください。

3. 前回から入った変更を一覧にして、変更履歴の節を書く。

   git log --oneline v1.8.1..main

   確認： grep -n '^## ' CHANGELOG.md の結果で、## 1.9.0 が ## 1.8.1 より上に並びます。

   うまくいかないとき：新しい節を、最新リリースの節より上に移してください。

4. アップグレード用に、テンプレートのハッシュを調べる。

   node skills/glance-explainer/scripts/upgrade.mjs --hash skills/glance-explainer/assets/template.html

   確認： 16桁の16進数が表示されます。KNOWN に載っていれば、何も足しません。載っていなければ、'digits': '1.9.0', を追加します。

   うまくいかないとき： worktree の最上位フォルダから実行してください。

つまり：手順4まで終えると、ブランチに新しいバージョン、変更履歴、ハッシュがそろいます。

この章のポイント：リリースブランチは worktree で始め、バージョン、変更履歴、ハッシュをそろえて終わります。

おさらい：ブランチに新しいバージョン、変更履歴、ハッシュがそろっています。

5. 同梱のページを新しいバージョンに合わせる。

   node skills/glance-explainer/scripts/upgrade.mjs skills/glance-explainer/assets/gallery.html skills/glance-explainer/examples skills/explainer-gather/examples docs/index.html docs/roadmap.html

   確認：どの行も version mark set、upgraded、already current のどれかになります。

   うまくいかないとき： skipped: custom styles は、手で編集した跡があるという意味です。テンプレートの style と script を貼り付けます。

6. 2つの確認を実行する。

   node tools/check-repo.mjs
   claude plugin validate --strict .

   確認：出力の末尾が all checks passed と Validation passed で、どちらも終了コードは0です。

   うまくいかないとき： FAIL の行をひとつずつ直します。バージョンの不一致は、手順2で番号の書き換えが漏れたということです。

7. コミットしてプッシュし、プルリクエストを出す。

   git add -A && git commit -m "chore(release): 1.9.0"
   git push -u origin release/1.9.0
   gh pr create --title "Release 1.9.0: public examples" --fill

   確認： gh pr checks --watch の最後に check が pass と表示されます。なお、site ジョブはプルリクエストではスキップされます。

   うまくいかないとき： gh pr checks --web を実行するとログが開きます。FAIL の行を直して、もう一度プッシュします。

つまり：まず自分のマシンで確認を実行し、そのあと CI がリポジトリの確認をもう一度実行します。

この章のポイント：同梱ページを更新し、2つの確認を通してから、プルリクエストを出します。

おさらい：プルリクエストを出し、check ジョブが通っています。

8. プルリクエストをマージし、ブランチを削除する。

   gh pr merge --merge
   git push origin --delete release/1.9.0

   確認：まず git fetch を実行します。続けて git log origin/main -1 --oneline を実行すると、自分のプルリクエストの名前が表示されます。

   うまくいかないとき： check ジョブが終わるのを待ちます。main が進んでいたら、origin/main をマージしてプッシュします。

9. マージにタグを付け、タグをプッシュする。

   git tag -a v1.9.0 -m "1.9.0: public examples" origin/main
   git push origin v1.9.0

   確認： git ls-remote --tags origin v1.9.0 でタグが表示されます。

   うまくいかないとき： already exists と出たら、すでに誰かがタグを付けています。先に git show v1.9.0 で中身を確認してください。

10. 変更履歴から GitHub リリースを作る。

    sed -n '/^## 1.9.0/,/^## 1.8.1/{//!p}' CHANGELOG.md > ../notes.md
    gh release create v1.9.0 --title "1.9.0: public examples" --notes-file ../notes.md

    確認： gh release view v1.9.0 でタイトルと、1.9.0 の変更履歴の本文が表示されます。

    うまくいかないとき： ../notes.md には、1.9.0 の節だけを入れてください。

11. 手元のプラグインを更新する。

    claude plugin marketplace update glance-explainer
    claude plugin update glance-explainer@glance-explainer

    確認：再起動後、claude plugin list の結果に Version: 1.9.0 と表示されます。

    うまくいかないとき：まだ古いままなら、2つのコマンドをこの順に実行して、もう一度再起動します。

つまり：マージ、タグ、リリースは別々の操作で、確認もそれぞれ別です。

gh run list --workflow ci --branch main --limit 1

この章のポイント：マージ、タグ付け、リリースの順に進め、最後に手元のプラグインを更新して再起動します。

おさらい：リリースはマージ、タグ、GitHub リリースの3つで、どれも元に戻せます。

• マージの前プルリクエストを閉じて、worktree を削除します。main には何も届いていません。
• マージのあと、タグの前新しいプルリクエストでマージをリバートし、もう一度確認を通します。
• タグとリリースのあとリリースとタグを削除します。ここでは、リリースはロックされていません。
• ユーザーが更新したあと回収はできません。パッチリリースを出して直します。

つまり：早く止めるほど、戻すコストは小さくなります。このリポジトリには、素早く直した前例があります。1.8.1 は、1.8.0 の約3時間後に出ました。

# before the merge (run the second line from the main checkout)
gh pr close --comment "Not shipping"
git worktree remove .claude/worktrees/release-1.9.0

# after the merge, before the tag
git revert -m 1 <merge commit>

# after the tag and the release
gh release delete v1.9.0 --cleanup-tag --yes
git tag -d v1.9.0

この章のポイント：進んだところまで戻し、ユーザーが更新したあとは修正版で直します。