| name | hotfix |
| description | ZpDIC Online に緊急のバグ修正 (ホットフィックス) を施し、リリースするための手順。すでに公開済みの master に対して、develop の開発を待たずに緊急でバグ修正を反映・公開したいときに使う。「ホットフィックスして」「緊急でバグを直して公開して」「hotfix ブランチを切って」「本番の不具合を今すぐ直したい」など、緊急のバグ修正・ホットフィックスに関する依頼が出たら必ずこの skill を使うこと。master から hotfix ブランチを切り、バージョンインクリメント・master へのマージ・タグ付け・develop への反映・origin への push という一連の定型作業を、固定のコミットメッセージとタグメッセージで正確に実行する。 |
ホットフィックス手順
ZpDIC Online に緊急のバグ修正 (ホットフィックス) を施し、新しいバージョンとしてリリースする。
公開中の master から hotfix/<yyyymmdd> ブランチを切ってバグを修正し、バージョンを上げて master にマージしてタグを付け、develop にも反映してから origin に push する。
各コミットメッセージ・マージメッセージ・タグメッセージは固定の文言を使う。
勝手に言い換えたり、英語にしたりしないこと。
全体の流れ
- 事前確認 (working tree)
master ブランチをチェックアウトhotfix/<yyyymmdd> ブランチを作成 → ここで一旦中断し、バグ修正の実装を促す- (バグ修正完了後) ビルドが通るかの確認
- バージョン番号のインクリメント
- バージョン変更のコミット
- 実行前の最終確認 (確認ゲート)
master へのマージ- タグ付け
develop に戻り hotfix ブランチをマージ- 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 する。
