hotfix

name	hotfix
description	ZpDIC Online に緊急のバグ修正 (ホットフィックス) を施し、リリースするための手順。すでに公開済みの master に対して、develop の開発を待たずに緊急でバグ修正を反映・公開したいときに使う。「ホットフィックスして」「緊急でバグを直して公開して」「hotfix ブランチを切って」「本番の不具合を今すぐ直したい」など、緊急のバグ修正・ホットフィックスに関する依頼が出たら必ずこの skill を使うこと。master から hotfix ブランチを切り、バージョンインクリメント・master へのマージ・タグ付け・develop への反映・origin への push という一連の定型作業を、固定のコミットメッセージとタグメッセージで正確に実行する。

ホットフィックス手順

ZpDIC Online に緊急のバグ修正 (ホットフィックス) を施し、新しいバージョンとしてリリースする。 公開中の master から hotfix/<yyyymmdd> ブランチを切ってバグを修正し、バージョンを上げて master にマージしてタグを付け、develop にも反映してから origin に push する。

各コミットメッセージ・マージメッセージ・タグメッセージは固定の文言を使う。 勝手に言い換えたり、英語にしたりしないこと。

全体の流れ

1. 事前確認 (working tree)
2. master ブランチをチェックアウト
3. hotfix/<yyyymmdd> ブランチを作成 → ここで一旦中断し、バグ修正の実装を促す
4. (バグ修正完了後) ビルドが通るかの確認
5. バージョン番号のインクリメント
6. バージョン変更のコミット
7. 実行前の最終確認 (確認ゲート)
8. master へのマージ
9. タグ付け
10. develop に戻り hotfix ブランチをマージ
11. origin への push

破壊的・外部反映を伴う操作 (マージ・タグ・push) に入る前に、Step 7 の「実行前の最終確認」でユーザーに一度確認してから進めること。

このスキルは 2 段階に分かれている。 Step 3 でブランチを作成したら一旦手を止め、バグ修正の実装が終わってユーザーからホットフィックス手順の続きを依頼されてから Step 4 以降を実行する。

Step 1: 事前確認

現在の working tree の状態を確認する。

git status

確認する内容:

• working tree が clean であることを確認する。未コミットの変更がある場合は中断してユーザーに報告する。

開始時のブランチは問わない (どのブランチにいても構わない)。 次の Step 2 で master に移る。 working tree が clean である場合のみ次に進む。

Step 2: master ブランチをチェックアウト

公開中の master に移る。

git checkout master

ホットフィックスは公開済みのコードに対して行うため、ローカルの master を origin の最新に揃えてから始める。

git fetch origin master
git merge --ff-only origin/master

注意点:

• ここは fast-forward のみ (--ff-only) で揃える。fast-forward できない (ローカル master が origin と乖離している) 場合は中断してユーザーに報告する。

Step 3: hotfix/<yyyymmdd> ブランチを作成

master から hotfix/<yyyymmdd> という名前のブランチを切ってチェックアウトする。 <yyyymmdd> は今日の日付 (例: 2026 年 7 月 8 日なら hotfix/20260708)。

まず <yyyymmdd> に入れる今日の日付を取得する。 実行環境のタイムゾーンが JST とは限らず、また Windows・クラウドなど環境もまちまちなため、必ず JST を明示して取得する。 コマンド置換 ($(...)) をブランチ作成コマンドに直接埋め込むと Windows 等で動かないので、日付は先に単独で取得し、その結果の文字列を使ってブランチ名を組み立てる。

date '+%Y%m%d' --date='TZ="Asia/Tokyo" now'

または Python で datetime.now(timezone(timedelta(hours=9))).strftime("%Y%m%d") から得る。

求めた日付 (例として 20260708 が得られたとする) を使ってブランチを切る。

git checkout -b hotfix/20260708

注意点:

• ブランチ名の 20260708 の部分は、上で実際に取得した日付に置き換える ($(...) をそのまま git checkout に渡さない)。
• 同名ブランチが既に存在する場合は、末尾に -2 のような連番を付ける。

チェックアウトできたら、その旨 (作成したブランチ名) をユーザーに伝え、バグ修正の実装を行うよう促す。

具体的なバグ修正の実装は、ユーザー自身が裏で行うか、同じセッションで修正内容を Claude に伝えて実装させるかのどちらかになる。 どちらにしてもバグ修正そのものはこのスキルの範疇外である。

ここで一旦手を止める。 バグ修正の実装が終わり、ユーザーからホットフィックス手順の続きをするよう依頼されたら、Step 4 以降に進む。

Step 4: ビルドが通るかの確認

リリース前に、本番ビルドが正常に通ることを確認する。

npm run build

注意点:

• ビルドが失敗した場合は、ここで中断してユーザーにエラー内容を報告する。バージョンインクリメント以降の操作には進まない。
• ビルドが成功した場合のみ次に進む。

Step 5: バージョン番号のインクリメント

package.json の version フィールドを読み取る。 値は semver 形式 (X.Y.Z)。

ホットフィックスでは基本的に patch (Z) をインクリメントする (X.Y.Z → X.Y.(Z+1))。

そのため AskUserQuestion では、patch を上げて良いか (すなわちインクリメント後のバージョンが X.Y.(Z+1) で良いか) をユーザーに確認する。 質問文には現在のバージョンと patch インクリメント後のバージョンを具体的に示す (例: 「3.25.0 → 3.25.1 (patch を上げます) でよいですか」)。

選択肢は以下のようにする。

• patch を上げる — インクリメント後のバージョンを X.Y.(Z+1) にする (基本はこちら)。
• その他 (major, minor など) — patch 以外を上げたい場合。ユーザーがこちらを選んだ場合は、major (X.Y.Z → (X+1).0.0) か minor (X.Y.Z → X.(Y+1).0) か、どのバージョンにするかを改めて確認する。

インクリメント後のバージョン番号 (以降この手順では X.Y.Z と表記) を確定させ、package.json の version の値だけを更新する。 他のフィールドには触れない。

Step 6: バージョン変更のコミット

package.json の変更のみを hotfix/<yyyymmdd> にコミットする。 他のファイルを巻き込まないよう、明示的に package.json だけをステージする。

git add package.json
git commit -m "バージョン番号を変更"

コミットメッセージは バージョン番号を変更 で固定。

Step 7: 実行前の最終確認 (確認ゲート)

ここから先 (マージ・タグ・push) は取り消しが難しく、push は外部 (origin) への反映を伴う。 実行前に、これから行う内容を簡潔にユーザーへ提示して一度確認を取る。

確認は AskUserQuestion を使い、ワンクリックで進められるようにする。 質問文や選択肢の説明の中で、以下の内容が伝わるようにする。

伝える内容:

• インクリメント後のバージョン (X.Y.Z)。
• これから master に hotfix/<yyyymmdd> をマージし、vX.Y.Z タグを付け、develop にも hotfix/<yyyymmdd> をマージした上で、develop・master・タグを origin に push すること。

選択肢は「進める」「中止する」のような 2 択にし、ユーザーが「進める」を選んだ場合のみ次に進む。

Step 8: master へのマージ

master をチェックアウトし、hotfix/<yyyymmdd> を fast-forward なし (--no-ff) でマージする。

git checkout master
git merge --no-ff hotfix/<yyyymmdd> -m "hotfixブランチをマージ"

注意点:

• --no-ff を必ず付け、マージコミットを作る (fast-forward させない)。
• マージコミットメッセージは hotfixブランチをマージ で固定。
• hotfix/<yyyymmdd> の部分は実際のブランチ名 (例: hotfix/20260708) に置き換える。

Step 9: タグ付け

直前のマージコミット (master 側) に注釈付きタグを付ける。

git tag -a vX.Y.Z -m "verX.Y.Zをリリース"

注意点:

• タグ名は vX.Y.Z (例: バージョンが 3.25.1 なら v3.25.1)。
• タグメッセージは verX.Y.Zをリリース で固定 (例: ver3.25.1をリリース)。

Step 10: develop に戻り hotfix ブランチをマージ

develop をチェックアウトし、hotfix/<yyyymmdd> を fast-forward なし (--no-ff) でこちらにもマージする。 これにより、ホットフィックスの内容が今後の開発ブランチにも反映される。

git checkout develop
git merge --no-ff hotfix/<yyyymmdd> -m "hotfixブランチをマージ"

注意点:

• --no-ff を必ず付ける。
• マージコミットメッセージは hotfixブランチをマージ で固定。
• hotfix/<yyyymmdd> の部分は実際のブランチ名に置き換える。
• マージ時にコンフリクトが起きた場合は自動で解決しようとせず、中断してユーザーに報告する。

Step 11: origin への push

develop ブランチ・master ブランチ・作成したタグを origin に push する。

git push origin develop master
git push origin vX.Y.Z

最後に、リリースしたバージョン (X.Y.Z) と付けたタグ (vX.Y.Z) をユーザーに報告する。

クラウド環境で実行中の場合

クラウド環境では GitHub 連携 (GitHub App) の権限が作業ブランチへの push に限定されており、タグ ref (refs/tags/*) の push は 403 Forbidden で失敗する可能性が高い (ブランチの push は成功する)。 これは一時的な問題ではなく恒常的な制約である。

そのため、クラウド環境ではタグの push (git push origin vX.Y.Z) は無理に試みず、スキップする。 ブランチ (develop・master) の push のみ行う。 タグはローカルに作成したまま残し、最後にユーザーへ「タグはローカル権限のある環境で以下を実行して push してほしい」と、コマンドを添えて報告する。

git fetch origin master
git tag -a vX.Y.Z origin/master -m "verX.Y.Zをリリース"
git push origin vX.Y.Z

ローカル環境で実行している場合は、従来どおりタグも push する。