release-manager

リリースマネージャー

バージョンの更新、変更履歴の作成、README の更新、ドキュメントの同期、ビルド、git タグの作成、GitHub リリース、PyPI/npm への公開まで、リリースのライフサイクル全体を自動化します。

アーキテクチャ（概要）

メインエージェントが処理を統括し、負荷の大きい手順（ファイルのスキャン、変更履歴の作成、ドキュメントの更新、ランディングページの更新）は、コンテキストを整理しておくために並列サブエージェントで実行します。アーキテクチャ図、リポジトリ同期のルール、サブエージェントの起動方法については、references/orchestration.md を参照してください。Agent ツールが使用できない場合は、同じ処理をインラインで実行します。

概要

通常、リリースでは以下の手順を順番に行います。変更を加える前に、各手順でユーザーに確認します。手順 1 で以降の手順を省略する場合があります： プロジェクトにリリースツール（.changeset、.releaserc、semantic-release、lerna.json）がすでに導入されている場合は、そのツールに従い、手順 2〜10 を省略します。

1. 事前チェック — 作業ツリーがクリーンで、リモートと同期されていることを確認
2. バージョンの決定 — 変更を分析し、semver に基づくバージョン更新を提案
3. バージョン番号の更新 — (サブエージェント) スキャンしてバージョン変更を提案
4. 変更履歴／リリースノートの作成 — (サブエージェント) git の履歴と PR を基に作成
5. README の更新 — (サブエージェント、ドキュメント更新と併せて実行) バージョンバッジ、変更履歴の項目
6. ドキュメントの更新 — (サブエージェント) プロジェクトのドキュメントをすべて同期 6b. ランディングページの更新 — (サブエージェント、3〜6 と並行して実行) プロジェクトにランディングページがある場合、バージョン表示、ダウンロード／インストールの CTA、「新着情報」、機能の紹介を更新します。ランディングページがない場合は、何もせずに終了します。ドキュメントの手順には含まれず、独立した手順です。
7. ビルド — プロジェクトにビルド手順がある場合は実行
8. コミット、タグ付け、プッシュ — リリースコミットとタグを作成
9. GitHub リリース — リリースノートとともに GitHub で公開
10. レジストリへの公開 — PyPI および／または npm に公開

前提条件

• 作業ツリーがクリーンであること（またはユーザーの承認を得て stash していること）
• ローカルブランチが origin と同期されていること（同期コマンドについては references/orchestration.md を参照）
• 公開する場合：PyPI/npm の認証情報が設定済みであること。GitHub リリースの場合：gh CLI の認証が済んでいること

編集前のリポジトリ同期（必須）

既存のリポジトリでファイルを作成、更新、削除する前に、現在のブランチをリモートと同期します。

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

作業ツリーがクリーンでない場合は、まず stash して同期し、その後復元します。

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin がない場合、pull を実行できない場合、または rebase／stash で競合が発生した場合は、作業を中止し、続行する前にユーザーに確認します。

---

手順 1：事前チェック（インライン）

既存のリリースツール（.changeset、.releaserc、semantic-release の設定など）が見つかった場合は、以下の手動手順ではなく、そのツールに従います。この手順の後半にある「既存のリリースツールを確認する」を参照してください。

リポジトリがクリーンな状態であることを確認します。

git status --porcelain
git rev-parse --abbrev-ref HEAD
git fetch origin
git status -sb

コミットされていない変更がある場合は、stash するか、コミットするか、中止するかをユーザーに確認します。作業内容をユーザーに知らせずに破棄してはいけません。

既存のリリースツールを確認する

grep -E '"(release|version|publish)"' package.json 2>/dev/null
ls .releaserc* .changeset/ .versionrc* lerna.json 2>/dev/null

見つかった場合は、ユーザーに「このプロジェクトでは <tool> を使用しています。手動手順の代わりに、そのリリースコマンドを実行します。」と伝え、そのツールに従います。

---

手順 2：バージョンの決定（インライン）

最後のタグ以降の変更を分析します。

git tag --sort=-creatordate | head -10
git log $(git describe --tags --abbrev=0 2>/dev/null || echo "HEAD~50")..HEAD --oneline --no-merges

Conventional Commits に基づいて、バージョン更新を提案します。

• MAJOR — BREAKING: または !: を含むコミットがある場合
• MINOR — feat: がある場合（破壊的変更を除く）
• PATCH — fix:、docs:、chore:、refactor: などのみの場合

「vX.Y.Z 以降に N 件の機能、M 件の修正、K 件の破壊的変更があるため、vA.B.C をおすすめします。承認するか、変更しますか？」と提示します。判断に迷う場合は、PATCH より MINOR を優先します。

---

ステップ 3～6：サブエージェントの並列実行

ユーザーがバージョンを確認したら、4 つのサブエージェント（version-bumper、changelog-generator、docs-updater、landing-page-updater）を同じターンで起動し、並列実行します。landing-page-updater はまずランディングページが存在するか確認し、存在しない場合は何もせずスキップします。また、リリースに関する説明文だけを編集し、バージョン文字列の変更は version-bumper に任せることで、同じ行を編集しないようにします。完了後、品質確認のために必要に応じて release-reviewer を起動します（エージェント間の競合も検出します）。ワークスペースの完全なセットアップ、エージェントの起動パラメーター、結果の収集、適用順序、変更の適用ワークフローについては、references/orchestration.md を参照してください。

---

ステップ 7：ビルド（インライン）

ビルドコマンドを検出します：

[ -f package.json ] && grep -q '"build"' package.json && echo "npm run build"
[ -f Makefile ] && grep -q '^build:' Makefile && echo "make build"
[ -f Cargo.toml ] && echo "cargo build --release"
[ -f pyproject.toml ] && echo "python -m build"

実行前にユーザーに確認します。ビルドに失敗した場合は停止し、デバッグを支援します。ビルドが壊れたまま作業を続けてはいけません。ビルド手順がない場合はスキップし、その旨をユーザーに伝えます。

---

ステップ 8：コミット、タグ付け、プッシュ（インライン）

変更したファイル（バージョン変更、変更履歴、README、ドキュメント）をステージングしてコミットします：

git add <specific files that were changed>
git commit -m "chore(release): vX.Y.Z"
git tag -a vX.Y.Z -m "Release vX.Y.Z"

プッシュする前に確認します（「受け入れ基準」を参照）：

git push origin <branch>
git push origin vX.Y.Z

---

ステップ 9：GitHub リリース（インライン）

gh CLI が利用可能で、リポジトリが GitHub 上にある場合：

gh release create vX.Y.Z \
  --title "vX.Y.Z" \
  --notes-file CHANGELOG.md \
  --latest

.tar.gz、.zip、バイナリ、.skill ファイルなどの成果物パスが存在する場合は、コマンドの末尾に追加します。リリース URL をユーザーに共有します。

---

ステップ 10：パッケージレジストリへの公開（インライン）

プロジェクトが PyPI や npm に公開される場合は、完全なワークフロー（前提条件、ビルド、検証、アップロード、公開後の検証）について references/publishing.md を参照します。

---

想定される出力

リリースが正常に完了したら、エージェントは次の想定出力を表示します：

Release v2.4.0 complete.

Version bumped: pyproject.toml, package.json (1.3.1 → 2.4.0)
Changelog: CHANGELOG.md updated (8 commits: 3 features, 4 fixes, 1 breaking change)
Git tag: v2.4.0 (annotated) pushed to origin
GitHub release: https://github.com/owner/repo/releases/tag/v2.4.0
Published: PyPI — https://pypi.org/project/mypackage/2.4.0/

Post-release reminders:
- [ ] Announce on Discord
- [ ] Monitor for install issues (pip install mypackage==2.4.0)

エッジケース

• 慣例に沿ったコミットがない — バージョン変更を自動で提案できません。コミット一覧をそのまま表示し、semver に基づくバージョン変更を明示的に確認します。
• リモートが設定されていない — git remote の結果が空です。プッシュと GitHub リリースをスキップし、ローカルでのタグ付けのみを提案します。
• すでに公開済みのバージョン — 対象のバージョンが PyPI/npm に存在することを（pip index versions または npm view で）検出した場合、公開手順を中止し、再度バージョンを上げるか公開をスキップするかをユーザーに確認します。
• ビルド成果物がない — ビルド済み成果物が必要なプロジェクトでは、Step 7 が成功するまで公開を拒否します。

受け入れ基準

• 検出されたすべてのファイル（例：pyproject.toml、package.json、__version__）でバージョン文字列が一貫して変更されている
• CHANGELOG.md にリリースバージョンの新しい項目が追加されている
• 注釈付き git タグが作成され、origin にプッシュされている
• gh が利用可能な場合、リリースノート付きの GitHub リリースが作成されている
• 破壊的な操作または公開される操作（プッシュ、公開、GitHub リリース）の前に、ユーザーに確認している
• 完了後にリリース後のチェックリストが提示されている

ステップ完了レポート

各主要ステップの後に、ステータスレポートを出力します。完全なテンプレートとステップごとの形式は references/step-reports.md にあります。簡易形式：

◆ [Step Name] (step N of M — context)
··································································
  Check 1:    √ pass
  Check 2:    × fail — reason
  Criteria:   √ N/M met
  ____________________________
  Result:     PASS | FAIL | PARTIAL

リリース後のチェックリスト

一般的な後続作業についてユーザーに案内します：

• リリースを告知する（ブログ、ソーシャルメディア、Discord、Slack）
• プロジェクトでその規約を採用している場合は、次の開発版にバージョンを上げる（例：X.Y.Z-dev）
• GitHub マイルストーンがある場合はクローズする
• 問題が発生していないか監視する
• パッケージをインストールできることを確認する（pip install pkg==X.Y.Z、npm install [email protected]）

ヒント

• 破壊的な操作や公開される操作の前に確認する方法については、「受け入れ基準」を参照してください
• モノレポでは、各パッケージのバージョンを個別に扱います
• 既存の CHANGELOG 形式を尊重し、新しい項目だけを追加して、形式を変更しないでください
• リリースの途中で問題が起きた場合は、ローカルとリモートのタグを削除し、コミットをリバートして、ユーザーのロールバックを支援します

参照ファイル

• references/orchestration.md — アーキテクチャ、リポジトリ同期のルール、並列サブエージェントのワークフロー
• references/step-reports.md — ステップ完了レポートの完全なテンプレート
• references/publishing.md — PyPI / npm の公開ワークフロー
• agents/version-bumper.md — バージョン文字列を変更するサブエージェントのプロンプト
• agents/changelog-generator.md — 変更履歴を生成するサブエージェントのプロンプト
• agents/docs-updater.md — ドキュメントを更新するサブエージェントのプロンプト
• agents/landing-page-updater.md — ランディングページを更新するサブエージェントのプロンプト（存在しない場合はスキップ）
• agents/release-reviewer.md — 独立した品質レビューを行うサブエージェントのプロンプト