deployment-composer

デプロイ構成

リポジトリの実際のブランチ運用モデル、CI の設定、デプロイプロバイダー、リリースのリスクに基づき、必要最小限で安全なデプロイワークフローを構成します。あらゆるデプロイを同じチェックリストとして扱うのではなく、作業を適切なスキルに振り分けます。

許可された範囲

ユーザーの依頼と既存の承認の範囲内でのみ作業してください。このスキルを読み込んでも、新たな権限は付与されません。報告のみの依頼は報告のみとして扱い、依頼者が指定した対象、ホスト、プロバイダー、費用の上限を守ってください。範囲を拡大する場合は事前に確認し、これらの制限を委任先にも伝えてください。

契約

入力：

• リポジトリのルート
• 希望するリリース／デプロイの目標
• 任意の対象環境、ソースブランチ、ターゲットブランチ、PR 番号、プロバイダー

出力：

• デプロイ経路：リリース PR、プロバイダーによるデプロイ、CI のセットアップ、または修復
• 選択した委任先スキル
• 品質ゲートの状態
• 引き続き必要な確認

作成／変更するもの：

• 調査中は何も作成しません
• ローカルのリリースノートや PR 本文のファイルを作成する場合があります
• 確認ルールを満たした後に限り、release を通じてリリースを作成できます

外部への副作用：

• git／GitHub のメタデータとワークフローの状態を読み取ります
• 委任先スキルを通じてプロバイダーのデプロイコマンドを実行する場合があります

確認が必要な操作：

• 本番環境へのデプロイまたはマージの前
• ユーザーが PR の作成を明示的に依頼していない場合の、GitHub PR 作成の前
• 本番環境用フラグを使ったプロバイダーコマンドの実行前

委任先：

• release
• deploy-app
• github-fix-ci
• ec2-backend-deployer
• testing-cicd-init

組み合わせるスキル

段階	用途
release	対象となる trunk の SHA を確認したうえで、release-please、保護されたリリースワークフロー、またはタグを通じてリリースを作成します
deploy-app	ステージング／本番環境への一般的なデプロイチェックリスト、ローカルの品質ゲート、デプロイ後の監視
github-fix-ci	リリース PR またはデプロイ PR で失敗した GitHub Actions のチェック
ec2-backend-deployer	Docker + GitHub Actions + EC2 によるバックエンドデプロイのセットアップ
testing-cicd-init	GitHub Actions／テストのインフラがない、または脆弱な場合
プロバイダー固有のスキル	該当するスキルがある場合の Vercel、Docker、Turborepo、監視、またはアプリ固有のデプロイ

調査フェーズ

経路を選ぶ前に、必ず調査してください。

git status -sb
git remote -v
git branch -r
find . -maxdepth 3 -type f \( -name 'package.json' -o -name 'vercel.json' -o -name 'Dockerfile' -o -name 'docker-compose.yml' -o -name 'docker-compose.yaml' -o -name 'turbo.json' \)
find .github/workflows -maxdepth 1 -type f 2>/dev/null

GitHub リポジトリの場合：

gh repo view --json nameWithOwner,defaultBranchRef
gh workflow list

以下を確認します：

• 現在のブランチと作業ツリーの変更状態
• デフォルト（trunk）ブランチとリモートブランチの一覧
• CI プロバイダーと必須チェック
• デプロイプロバイダー：Vercel、EC2/Docker、GitHub Actions、カスタムスクリプト、または不明
• パッケージマネージャーと品質チェックのコマンド
• 対象環境：プレビュー、ステージング、本番

振り分けルール

リリース

ユーザーがリリースの作成を希望している場合：

1. release を使用します。対象となる trunk の SHA を確認し、リポジトリ独自のリリース方式でリリースを作成します。
2. staging と production は CI／タグによって制御されるデプロイ環境であり、git ブランチではありません。
3. チェックに失敗した場合は、github-fix-ci を使用します。

プロバイダーへの直接デプロイ

ユーザーが現在のブランチ／アプリを環境にデプロイすることを希望している場合：

1. ローカルのデプロイ前チェックとデプロイ後の検証には、deploy-app を使用します。
2. プロバイダーのセットアップまたは実行は、以下のように振り分けます。
   • Vercel プロジェクト：Vercel 固有のガイダンスまたは CLI を使用します。
   • EC2/Docker バックエンド：ec2-backend-deployer を使用します。
   • Turborepo：turbo.json を調査し、適切であれば影響範囲に応じたビルドを使用します。
   • プロバイダーが不明：実行前にスクリプトとワークフローファイルを調査します。
3. 明示的な確認なしに本番環境へデプロイしないでください。

CI のセットアップまたは修復

リポジトリに CI がない、または品質ゲートが脆弱な場合：

1. 基本的なチェックを追加するために、testing-cicd-init を使用します。
2. CI の準備ができたら、deploy-app を使用します。
3. 既存のチェックが失敗している場合は、github-fix-ci を使用します。

リリースノート

リリースにユーザー向けのノートまたは PR 本文が必要な場合：

1. コミット履歴に基づくユーザー向けノートを作成するには、notes モードで release を使用します。
2. 判明している場合は、マイグレーション、環境変数の変更、ロールバックに関する注意事項を含めます。

デプロイワークフロー

1. リポジトリの構成とデプロイプロバイダーを確認します。

2. ルーティングルールに従って、最も限定的な経路を選びます。

3. 直接デプロイする前に、リポジトリが指定するホスト上で、リポジトリ独自のフォーマット、リント、型チェックのスクリプトを実行します（設定されている場合は、テストとビルドも実行します）。 パッケージマネージャーを推測したり、連続して実行したりしないでください。スクリプトがない場合は、カバレッジの不足として報告します。 リリースでは、代わりに正確な SHA に対する CI を利用します（release を参照）。

4. 選択したリリースまたはデプロイの手順を実行します。

5. リモートチェックまたはデプロイ状況を待ちます。

6. デプロイ環境を検証します。

   • ヘルスエンドポイント
   • 重要なページ／API パス
   • 利用可能な場合は、ログまたは監視情報

7. 最終状況と阻害要因を報告します。

安全ルール

• 変更のあるワークツリーを隠さず、ローカルの変更がデプロイに含まれるかどうかを明示します。
• ブランチ保護や必須チェックを回避しないでください。
• 明示的な確認なしに、本番環境へマージまたはデプロイしないでください。
• staging 環境が設定されていると決めつけず、CI／デプロイ設定を確認してください。
• スキップされたチェックや存在しないチェックを成功扱いしないでください。
• 新しいデプロイコマンドを考案するより、既存のリポジトリスクリプトやワークフローを優先してください。
• プロバイダーを特定できない場合は、調査の後で停止し、不足している情報を報告してください。

出力形式

簡潔なデプロイ状況を返します。

Deployment route: [release PR / provider deploy / CI setup / repair]
Repository: [owner/repo]
Branches: [source] -> [target] or [current branch]
Provider: [Vercel/EC2/Docker/GitHub Actions/custom/unknown]
Checks: [passing/failing/pending/not configured]
Deployment: [not started/in progress/succeeded/failed]
Verification: [passed/failed/not available]
Needs confirmation: [production merge/deploy, if applicable]