菜单
ZpDIC Online を新しいバージョンとしてリリース (デプロイ) するための手順。develop ブランチで開発が一段落し、バージョンを上げて master に反映・公開したいときに使う。「デプロイして」「リリースして」「新しいバージョンを出して」「バージョンを上げて公開して」など、リリース・デプロイ・バージョン更新に関する依頼が出たら必ずこの skill を使うこと。git のバージョンインクリメント・master へのマージ・タグ付け・origin への push という一連の定型作業を、固定のコミットメッセージとタグメッセージで正確に実行する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | deploy |
| description | ZpDIC Online を新しいバージョンとしてリリース (デプロイ) するための手順。develop ブランチで開発が一段落し、バージョンを上げて master に反映・公開したいときに使う。「デプロイして」「リリースして」「新しいバージョンを出して」「バージョンを上げて公開して」など、リリース・デプロイ・バージョン更新に関する依頼が出たら必ずこの skill を使うこと。git のバージョンインクリメント・master へのマージ・タグ付け・origin への push という一連の定型作業を、固定のコミットメッセージとタグメッセージで正確に実行する。 |
ZpDIC Online を新しいバージョンとしてリリースする。
develop で開発した内容のバージョンを上げ、master にマージしてタグを付け、origin に push する。
各コミットメッセージ・マージメッセージ・タグメッセージは固定の文言を使う。 勝手に言い換えたり、英語にしたりしないこと。
master へのマージdevelop に戻る破壊的・外部反映を伴う操作 (マージ・タグ・push) に入る前に、後述の「実行前の最終確認」でユーザーに一度確認してから進めること。
現在のブランチと working tree の状態を確認する。
git status
確認する内容:
develop ブランチにいることを確認する。違うブランチにいる場合は、ここで中断してユーザーに報告する (勝手に develop に切り替えない)。両方を満たしている場合のみ次に進む。
クラウド環境 (Claude Code on the web) では、セッションは develop ではなく自動生成された作業ブランチ (claude/...) 上で開始する。
この場合に限り、以下の両方を満たすときは、確認を挟まずに自動的に develop に移動して手順を続行して良い。
develop の間に差分がないこと (現在のブランチの内容が origin/develop と一致していること)。まず git fetch origin develop してから比較する。この条件を満たす場合は、develop に移動し、ローカル develop が古ければ origin/develop に揃えて (fast-forward) 続行する。
上記のいずれかを満たさない場合 (develop との間に差分がある, ローカル環境である, working tree が clean でない等) は、これまで通り中断してユーザーに確認する。
リリース前に、本番ビルドが正常に通ることを確認する。
npm run build
注意点:
package.json の version フィールドを読み取る。
値は semver 形式 (X.Y.Z)。
AskUserQuestion を用いて、major, minor, patch のうちのどの部分をインクリメントするかをユーザーに確認する。
X) — X.Y.Z → (X+1).0.0Y) — X.Y.Z → X.(Y+1).0Z) — X.Y.Z → X.Y.(Z+1)インクリメント後のバージョン番号 (以降この手順では X.Y.Z と表記) を確定させ、package.json の version の値だけを更新する。
他のフィールドには触れない。
package.json の変更のみをコミットする。
他のファイルを巻き込まないよう、明示的に package.json だけをステージする。
git add package.json
git commit -m "バージョン番号を変更"
コミットメッセージは バージョン番号を変更 で固定。
ここから先 (マージ・タグ・push) は取り消しが難しく、push は外部 (origin) への反映を伴う。 実行前に、これから行う内容を簡潔にユーザーへ提示して一度確認を取る。
確認は AskUserQuestion を使い、ワンクリックで進められるようにする。
質問文や選択肢の説明の中で、以下の内容が伝わるようにする。
伝える内容:
X.Y.Z)。master に develop をマージし、vX.Y.Z タグを付け、develop・master・タグを origin に push すること。選択肢は「進める」「中止する」のような 2 択にし、ユーザーが「進める」を選んだ場合のみ次に進む。
master へのマージmaster をチェックアウトし、develop を fast-forward なし (--no-ff) でマージする。
git checkout master
git merge --no-ff develop -m "developブランチをマージ"
注意点:
--no-ff を必ず付け、マージコミットを作る (fast-forward させない)。developブランチをマージ で固定。直前のマージコミットに注釈付きタグを付ける。
git tag -a vX.Y.Z -m "verX.Y.Zをリリース"
注意点:
vX.Y.Z (例: バージョンが 3.25.0 なら v3.25.0)。verX.Y.Zをリリース で固定 (例: ver3.25.0をリリース)。develop ブランチ・master ブランチ・作成したタグを origin に push する。
git push origin develop master
git push origin 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 する。
develop に戻る作業ブランチを develop に戻して終了する。
git checkout develop
最後に、リリースしたバージョン (X.Y.Z) と付けたタグ (vX.Y.Z) をユーザーに報告する。
開発マイルストーンを管理している Notion のデータベースに、今回のリリースを反映する。
Notion の操作には Notion の MCP ツール (notion-query-data-sources, notion-update-page, notion-create-pages など) を用いる。
Step 3 で major もしくは minor バージョンをインクリメントした場合のみ行う。 patch アップデートの場合はこのステップをスキップし、そのまま Step 11 に進む。
対象のデータベース:
collection://08baa6dd-18b0-430a-83fb-5c4e0fd3a3ce名前 (タイトル) — ver X.Y.Z の形式 (ver の後に半角スペース, 例: ver 3.27.0)ステータス (select) — Released を設定するリリース日 (date, 表示形式 YYYY/MM/DD) — 更新・作成時は展開プロパティ date:リリース日:start に ISO 形式の日付 (YYYY-MM-DD) を渡すプロジェクト (relation) — 「ZpDIC Online (version 3)」プロジェクトのページ (https://app.notion.com/d044b0bb27c3486a80a22e291fe99062), 値は URL の JSON 配列文字列 ["https://app.notion.com/d044b0bb27c3486a80a22e291fe99062"] で渡す。まず対象ページが既に存在するか確認する。
notion-query-data-sources で、プロジェクト が「ZpDIC Online (version 3)」(d044b0bb27c3486a80a22e291fe99062) かつ 名前 が ver X.Y.Z のページを検索する。
SELECT url, "名前", "ステータス" FROM "collection://08baa6dd-18b0-430a-83fb-5c4e0fd3a3ce"
WHERE "名前" = 'ver X.Y.Z' AND "プロジェクト" LIKE '%d044b0bb27c3486a80a22e291fe99062%'
ページが存在するかどうかに応じて、以下の操作を行う。
そのページを notion-update-page (command: "update_properties") で更新する。
「今日の日付」は実際の現在の日付を用いる。
ステータス = Releaseddate:リリース日:start = 今日の日付 (YYYY-MM-DD)notion-create-pages で新たにページを追加する (parent は data_source_id: "08baa6dd-18b0-430a-83fb-5c4e0fd3a3ce")。
「今日の日付」は実際の現在の日付を用いる。
名前 = ver X.Y.Zステータス = Releaseddate:リリース日:start = 今日の日付 (YYYY-MM-DD)プロジェクト = ["https://app.notion.com/d044b0bb27c3486a80a22e291fe99062"]今回のリリースに含まれる変更内容を確認し、ユーザーが告知に使えるお知らせ文をまとめて提案する。
変更内容は、前回のリリースタグから今回のタグまでの差分から把握する。
git log <前回のタグ>..vX.Y.Z --no-merges --pretty=format:"%h %s"
コミットメッセージが簡素な場合は、git show などで実際の差分を確認し、ユーザーに見える機能追加・機能変更を中心に把握する。
お知らせ文の形式:
` で囲む) は Markdown の書式を使って良い。特定の記法や記号 (例: { と }) に言及するときはインラインコードを使うと良い。以下に過去のお知らせ文を 2 つ記載しておくので、文章の形式やトーンの参考にしてください。
過去のお知らせ文の例 1:
単語カードや例文カードの共有メニューから、その内容をスクリーンショット (PNG 画像) として保存できるようになりました。
辞書の内容を SNS などで紹介したいなどにご利用ください。
なお、画像の生成には数秒から十数秒ほどかかります。
API キー周りの UI も刷新しました。
これまで発行した API キーの最終使用日時を確認できるようになり、API キーが不要になった場合は削除することもできるようになりました。
辞書のインポート機能やエクスポート機能も強化しました。
これまでの OneToMany-JSON 形式に加え、「ZpDIC API 形式」と呼ばれる新しい形式でのインポートやエクスポートが可能になりました。
ZpDIC API 形式とは ZpDIC 内部の構造をそのまま保持した独自形式で、これを使うことで、OneToMany-JSON 形式では失われてしまう構造や情報を保ったままデータのやり取りができます。
過去のお知らせ文の例 2 (インラインコードの使用例を含む):
Markdown 機能で利用できるマークアップ記法の種類を増やし、辞書ごとにどの記法を利用するか選択できるようになりました。 特に、`{` と `}` で囲まれた部分を専用フォントで表示するという記法を追加しました。
後述する専用フォントの範囲設定とともにご利用ください。
専用フォントの設定において、そのフォントをどこに適用するかを辞書ごとに選択できるようになりました。
これまでは専用フォントは見出し語のみに利用されましたが、変化形や例文なども専用フォントで表示できます。
また、先述の通り、Markdown に `{`～`}` という記法が追加されています。
この記法を有効にした上で、専用フォントの適用範囲として「内容」を選択することで、内容欄の好きな箇所を専用フォントで表示させることができます。
なお、設定の「Markdown」項目は、「編集」タブから「表示」タブに移動していますので、ご注意ください。
dependabot が作成した依存パッケージ更新の PR をまとめて調査・マージするための手順。「dependabot の PR を見て」「dependabot の PR をマージして」「依存パッケージの更新をまとめて処理して」「dependabot を片付けて」「依存関係の更新 PR を整理して」など、dependabot・依存パッケージ更新 PR の調査やマージに関する依頼が出たら必ずこの skill を使うこと。現在 open な dependabot PR を全て取得し、各更新がアプリ本体に与える影響を調査して表で提示し、ユーザーの選択に従って固定メッセージで squash マージし、最後にローカルへ反映する。
サーバーサイドの MongoDB インデックスをクエリの使用状況に合わせて整備する手順。「インデックスを整備して」「インデックスを見直して」「必要なインデックスを追加して」「不要なインデックスを削除して」「クエリとインデックスを同期して」など、MongoDB のインデックスの整備・見直しに関する依頼が出たら必ずこの skill を使うこと。server 内の全クエリ呼び出しを棚卸しし、Typegoose の @index 宣言と突き合わせて、新たに必要になったインデックスの追加と不要になったインデックスの削除を行い、develop から切ったブランチで PR を作成する。@index の削除は DB からは自動では消えないため、手動 dropIndex 用のコマンドを PR に記載する。
client アプリの国際化メッセージファイル (client/message の ja.yml, en.yml, eo.yml) を整備する手順。「メッセージファイルを整備して」「未設定のメッセージを追加して」「メッセージを並び替えて」「国際化メッセージを整えて」など、メッセージファイルの整備・未設定メッセージの補完・並び替えに関する依頼が出たら必ずこの skill を使うこと。コードが参照しているのにメッセージファイルにないキーを検出して追加し (ja にあれば翻訳, なければ <NOT SET>)、各ファイルを toast→atom→compound→form→page→other のセクション順かつセクション内アルファベット順に並び替えた上で、develop から切ったブランチで PR を作成する。
ZpDIC Online に緊急のバグ修正 (ホットフィックス) を施し、リリースするための手順。すでに公開済みの master に対して、develop の開発を待たずに緊急でバグ修正を反映・公開したいときに使う。「ホットフィックスして」「緊急でバグを直して公開して」「hotfix ブランチを切って」「本番の不具合を今すぐ直したい」など、緊急のバグ修正・ホットフィックスに関する依頼が出たら必ずこの skill を使うこと。master から hotfix ブランチを切り、バージョンインクリメント・master へのマージ・タグ付け・develop への反映・origin への push という一連の定型作業を、固定のコミットメッセージとタグメッセージで正確に実行する。
git ワークツリーを用いた作業が終わり、ワークツリーのクリーンアップ (後片付け) を指示されたときの手順。「ワークツリーを片付けて」「ワークツリーをクリーンアップして」「作業が終わったのでワークツリーを消して」などの依頼が出たら必ずこの skill を使うこと。ワークツリー設定の解除とブランチ削除を行ったあと、ワークツリーフォルダ内のファイルは削除を試みるが (失敗しても再試行しない)、ワークツリーフォルダ自身は削除せず手動削除を促す、という固定の手順を踏む。