version-release

バージョンリリースのワークフロー

このスキルはルーターです。詳細な手順は references/ にあります。

対象範囲（重要）

このスキルの対象は、次の項目のみです。

1. リリースブランチ／PR のワークフロー
2. CI のトリガー制約（auto-tag-release.yml）
3. GitHub リリースノートの作成

このスキルは docs/changelog/*.mdx の作成には対応していません。
ユーザーからウェブサイトの変更履歴ページを求められた場合は、../docs-changelog/SKILL.md を読み込んでください。

必須の併用スキル

すべての /version-release の実行時に、必ず次を読み込み、適用してください。

• ../../../DESIGN.md（Voice & Content）

概要

主な開発ブランチは canary です。日々の開発はすべて canary で行います。リリース時には、canary を main にマージします。通常のリリース PR（🚀 release: …、release/*、hotfix/*）では、PR がオープンしている間に release-pr-version.yml が package.json のバージョンを更新するコミットを作成します。マージ後、auto-tag-release.yml がマージコミットにタグを付け、GitHub リリースを作成します。sync-main-to-canary は main へのプッシュ時に実行されます。

実際に使用されるリリース種別は 2 つのみです（メジャーリリースは非常にまれなため、無視してかまいません）。

種別	用途	頻度	ソースブランチ	PR タイトルの形式	バージョン	参照
Minor	機能の反復リリース	~4 週間ごと	canary	🚀 release: v{x.y.0}	手動設定	references/minor-release.md
Patch	週次リリース／ホットフィックス／モデル／DB 移行	~週次または必要に応じて	canary または main	Custom（例：🚀 release: 20260222）	自動でパッチを +1	references/patch-release-scenarios.md

リリースノート本文の作成については（リリース種別を問わず）、references/release-notes-style.md を参照してください。

自動リリースのトリガールール（auto-tag-release.yml）

PR が main にマージされた後、CI は次の優先順位に基づいてリリースするかどうかを判断します。

1. Minor リリース（バージョンを明示）

PR タイトルが 🚀 release: v{x.y.z} に一致する場合、タイトルに記載されたバージョン番号を使用します。

2. Patch リリース（パッチを自動で +1）

次の優先順位でトリガーされます。

• ブランチ名の一致：hotfix/* または release/* の場合、直接トリガーされます（タイトルの判定をスキップします）
• タイトルのプレフィックスの一致：次のタイトルプレフィックスを持つ PR がトリガーされます。
  • style / 💄 style
  • feat / ✨ feat
  • fix / 🐛 fix
  • refactor / ♻️ refactor
  • hotfix / 🐛 hotfix / 🩹 hotfix
  • build / 👷 build

3. トリガーなし

上記の条件に一致しない PR（例：docs、chore、ci、test）は、main にマージされてもリリースをトリガーしません。

自動アクション

1. リリース PR 上（release-pr-version.yml）— package.json が最新でない場合、🔖 chore(release): release version v{x.y.z} を PR のヘッドにコミットします。Minor のタイトル 🚀 release: v{x.y.z} ではそのバージョンを使用し、週次リリース／release/*／hotfix/* では最新の安定版タグにパッチを加えます。
2. マージ後（auto-tag-release.yml）— マージコミットに v{x.y.z} のタグを付け、GitHub リリースを作成します。Patch バージョンは最新の安定版タグに +1 したもので、package.json のバージョンに +1 したものではありません。
3. sync-main-to-canary — main へのプッシュ時に実行されます。

エージェントのアクションガイド

ユーザーからリリースを依頼された場合：

事前確認（すべてのリリース種別に適用）

リリースブランチを作成する前に、ソースブランチを確認してください。

• 週次リリース（release/weekly-*）：canary からブランチを作成する必要があります
• その他すべてのリリース／ホットフィックスブランチ：main からブランチを作成する必要があります。git merge-base --is-ancestor main <branch> && echo OK を実行してください
• ブランチの作成元が正しくない場合は、正しいベースから作り直してください

ルーティング

適切なリファレンスを選び、最初から最後までその手順に従ってください。

• マイナーリリース → references/minor-release.md
• パッチリリース（週次／ホットフィックス／モデルのリリース／DB マイグレーション） → references/patch-release-scenarios.md
• PR 本文／リリースノートの作成（リリースの種類を問いません） → references/release-notes-style.md

厳守事項（すべてのリリースに適用）

• package.json のバージョンを手動で変更しないでください。CI が処理します。
• タグを手動で作成しないでください。CI が処理します。
• マイナーリリースの PR タイトルの形式は厳守してください（🚀 release: v{x.y.z}）。
• パッチリリースの PR に明示的なバージョン番号は不要です。
• リリースに関する事実は正確に保ち、メトリクスや提供状況に関する記述を捏造しないでください。リリースノートの入力情報（比較元のベース、PR の参照情報、コントリビューター一覧）は、references/release-notes-style.md の § Computing Inputs に従い、必ず git から取得してください。記憶や説明文から取得してはいけません。