volcengine-prepare

Volcengine Prepare Skill

リポジトリを分析し、実現可能な Volcengine のデプロイ方法を説明して、リソース管理の方法を決定します。このスキルは意思決定を支援するものであり、ワークフローエンジンとして扱わないでください。詳細なレポートの作成を目的にしないでください。

---

0. 基本動作

既定のフロー：

1. ローカルパスまたは Git URL からリポジトリを特定します。
2. アナライザーを実行して、言語、フレームワーク、ポート、Docker／compose の構成、依存関係、マイグレーション、エントリーポイント、およびデプロイ可能なサービスの範囲を特定します。
3. 認証情報が利用可能な場合は、現在の Volcengine の ID とリージョンを任意で確認します。
4. デプロイ可能なサービスの範囲が明確になってから、ECS／VKE／veFaaS の優先順位付きリストを提示します。実質的に実現可能な方法をすべて含め、それぞれの利点やコストがかかる理由を説明します。機械可読なモード値には ecs | vke | vefaas を使用します。
5. references/deploy-mode-heuristics.md に従って、リソース管理方法（cli または iac）を推奨し、ユーザーに確認を求めます。
6. 製品やライフサイクルに関する曖昧さ、リソースの再利用、リソース管理方法についてのみ質問します。ユーザーが「あなたが決めて」と言った場合は、優先順位が最も高いランタイムの方法、これらのルールに基づく推奨リソース管理方法、新規の分離されたリソースを使用します。
7. 複数のステップにまたがって作業を続ける場合に限り、.volcengine/ に最小限の状態を保存します。

ECS／VKE／veFaaS の優先順位を付ける前に、具体的なデプロイ対象を特定してください。対象は、各方法で実行、コンテナ化、公開、または配信できるリポジトリ、サブディレクトリ、コマンド、アーティファクト、静的出力、既存のクラウドアプリまたは関数です。ファイル単位の兆候は根拠であって、結論ではありません。Dockerfile、compose ファイル、package.json、フレームワークの依存関係、または build／dev／test スクリプトだけでは、リポジトリがデプロイ可能であることの証明にはなりません。

推奨時に、ツールの依存関係を厳密に確認しないでください。選択された方法に固有のツールは、ユーザーが方法を選んだ後にのみ確認します。

状態ディレクトリ：

.volcengine/
  deploy-choice.json       # chosen mode/resource strategy, when persistence is useful
  created-resources.json   # maintained by deploy only for CLI fast path
  terraform/               # IaC working files, only when infra_management=iac
  iac-outputs.json         # Terraform outputs consumed by deploy

一時的なクローンやキャッシュにのみ /tmp を使用します。

---

1. リポジトリの特定と分析

Git URL の場合は、一時キャッシュにクローンします。ローカルパスの場合は、その場で分析します。

input="${1:-.}"
if [[ "$input" =~ ^(https?|git@) ]]; then
  repo_name=$(basename "$input" .git)
  cache_dir="/tmp/volcengine-prepare/$repo_name"
  mkdir -p "$cache_dir"
  [ -d "$cache_dir/src/.git" ] || git clone --depth 1 "$input" "$cache_dir/src"
  repo_dir="$cache_dir/src"
else
  repo_dir=$(cd "$input" && pwd)
  repo_name=$(basename "$repo_dir")
fi
git_sha=$(cd "$repo_dir" && git rev-parse --short HEAD 2>/dev/null || echo "unversioned")

次を実行します。

analysis=$(bash scripts/analyze-repo.sh "$repo_dir")
echo "$analysis" | jq .

重要な調査結果を平易な言葉で示します。

Project: <repo_name> @ <git_sha>
Runtime: <language> / <framework>
Deployable subdir: <deploy_subdir or repo root>
Deployable surface: <web service | rpc service | http api | static/html site | full-stack app | user-specified service | unclear>
Entrypoint: <entrypoint>
Port: <port>
Packaging signals: Dockerfile=<yes/no>, compose=<yes/no if detected>
Dependencies: <mysql, redis, ...>
Migrations: <paths or none>

アナライザーが具体的な ECS／VKE／veFaaS のデプロイ対象を特定できない場合は、方法を推奨する前に、どのサブディレクトリ、サービス、コマンド、アーティファクト、静的出力、または既存の veFaaS アプリ／関数をデプロイするのかユーザーに尋ねてください。リポジトリの主な内容がアプリケーションのサービス範囲ではなく、ビルドツール、パッケージ化、サンプル、ドキュメント、または再利用可能なコードに見える場合は、強い推奨ではなく確認にとどめてください。

デプロイ対象とは、ECS、VKE、または veFaaS で実行、コンテナ化、公開、または配信できるものです。判断に役立つ根拠には、以下のものがありますが、これらに限りません。

• 起動コマンドを持つ、長時間稼働するプロセス
• リッスンするポート、または RPC／API／HTTP ルート
• 配信を目的とした静的／HTML サイトのエントリーポイントまたはビルド出力
• ヘルスチェックまたはスモークテスト用エンドポイント
• サービス境界が明確なフロントエンドとバックエンド／API の構成要素
• サービス、サブディレクトリ、コマンド、アーティファクト、またはランタイム対象を明示するユーザーの指示

Dockerfile、パッケージスクリプト、またはビルドツールだけを根拠に、デプロイ可能だと判断しないでください。

---

2. 任意のクラウド ID 確認

VOLCENGINE_ACCESS_KEY、VOLCENGINE_SECRET_KEY、および VOLCENGINE_REGION が設定されている場合は、ID を確認します。

ve sts GetCallerIdentity

~/.volcengine/config.json は読み込まないでください。シークレットが含まれている可能性があります。環境変数が設定されていない場合も推奨を続け、選択した方法を実行する際に認証情報を確認するとユーザーに伝えてください。

直近の選択にクラウドサービスの利用可否が影響する場合は、読み取り専用のプローブを実行します。

services=$(bash scripts/check-region-services.sh)
echo "$services" | jq .

権限またはリージョンに関する注意事項は、それに該当する選択肢に示してください。その選択肢を隠さないでください。

事前確認は参考情報であり、必須条件ではありません。クォータや権限を簡単に確認できる場合は、その結果をリスクとして提示します。

<quota/permission> may be insufficient; continuing could fail when creating resources. Proceed anyway?

アカウントの実名認証や残高を確実に照会できない場合は、確認したと偽らず、簡潔に注意を促してください。

Creating cloud resources may require a real-name-verified account with sufficient balance/credit; if creation fails, resolve the account status in the console first.

3. デプロイ方法を提案する

詳細な判断ルールについては、references/deploy-mode-heuristics.md を使用します。recommended=true/false のフラグやスコアリングの内部情報ではなく、順位を付けたリストを提示してください。デプロイ可能な対象が明確でない場合は、まず曖昧な点を示し、順位付けの前に必要最小限の確認質問をしてください。

実質的に有効な選択肢はすべて含めてください。リポジトリやユーザーの依頼から選択肢が明らかに除外される場合、ECS／VKE／veFaaS のすべてを無理に比較しないでください。除外した理由がユーザーの判断に役立つ場合に限り、実行不可能な選択肢に言及してください。

• ECS：VM 方式です。Web／API／RPC サービス、フルスタックアプリ、静的サイトを配信するプロセス、バイナリ、Docker／compose アプリ、ワーカー、スケジュールされたコマンド、OS／ネットワーク／ディスク／デバッグの制御が必要なアプリなど、Linux VM 上で実行できる対象に最適です。
• VKE：コンテナ／Kubernetes 方式です。マルチサービスアプリ、Web／API／RPC コンテナ、ワーカー、Jobs／CronJobs、ローリングアップデート、レプリカ、HPA、Ingress／Service、GPU ワークロード、本番環境でのコンテナ運用など、コンテナ化された対象や Kubernetes に適した対象に最適です。
• veFaaS：サーバーレス方式です。対象が volcengine-vefaas スキルのワークフローに適合する場合に限り最適です。対応する Web／API またはフロントエンド／静的サイトのフレームワーク、あるいは既存の veFaaS アプリ／関数が該当します。長時間実行するワーカー、複数サービスのオーケストレーション、複雑な移行、未対応のイベント／タスク／トリガーの作成、カスタムのシステム依存関係、利用可能な API Gateway がない場合は、ECS／VKE を優先してください。ユーザーが veFaaS を選んだ場合は、デプロイのために volcengine-vefaas スキルに切り替えるか呼び出してください。それが失敗した場合は、ユーザーが再試行するか ECS／VKE を選べるよう、メインのフローに戻ってください。

以下を含めてください。

• その順位にした理由
• おおよそのコスト水準（low、medium、medium-high）
• 運用上のトレードオフ
• ユーザーがその選択肢を選んだ場合に判明しているブロッカーや必要なセットアップ
• リソース管理の推奨（iac または cli）とその理由

ユーザーが選択する前に、すべてのツールを確認しないでください。セットアップの必要性は、判断に役立つ情報として伝えてください。リソース管理の推奨は references/deploy-mode-heuristics.md に基づいて示しますが、その内部参照パスをユーザーに伝えないでください。

Resource management recommendation: <iac|cli>. Reason: <one short user-facing reason>. Confirm `iac` or `cli`.
Choosing VKE will check kubectl; if you choose IaC it will also check terraform/provider availability.
Choosing veFaaS switches to / calls the `volcengine-vefaas` skill to check the vefaas CLI, login status, and framework detection; on failure it returns here so you can fix it and retry, or switch to ECS/VKE.

---

4. 必要な質問だけをする

順位付きリストを提示した後、安全に推測できないことだけを質問してください。

1. Deployment mode: defaults to the top-ranked option. Choose ECS / VKE / veFaaS (recorded as `ecs` / `vke` / `vefaas`).
2. Resource strategy: defaults to a new isolated project deploy-<repo> with new resources; you may also reuse existing resources.
3. Database product/engine, only when a managed database is detected or requested: choose `rds/mysql`, `rds/postgresql`, `rds/sqlserver`, `aidap/supabase`, or `aidap/postgresql`.
4. Resource management: recommend <cli|iac>; confirm whether to use the CLI resource ledger or Terraform/IaC.

MySQL の依存関係には、ユーザーがマネージド RDS を拒否しない限り、database_product=rds と database_engine=mysql を使用してください。SQL Server の依存関係には、database_product=rds と database_engine=sqlserver を使用してください。PostgreSQL の依存関係では、まずユーザーの明示的な意向を優先してください。RDS／マネージド RDS インスタンスの明示的な依頼には RDS PostgreSQL、AIDAP／サーバーレス PostgreSQL の明示的な依頼には AIDAP PostgreSQL、Supabase の明示的な依頼には AIDAP Supabase を選択してください。製品が曖昧で、ユーザーが選択を委任していない場合は、RDS PostgreSQL、AIDAP PostgreSQL、AIDAP Supabase はそれぞれ異なる選択肢であるため、質問してください。

Terraform／IaC を使用するかどうかは、明示的に質問してください。references/deploy-mode-heuristics.md に従って推奨を示しますが、デフォルトとして扱わないでください。ユーザーに iac または cli を確認してください。

ユーザーが「決めて」と言った場合は、次を使用してください。

• デプロイ方式：最も順位の高い選択肢
• リソース：新しい専用の Volcengine プロジェクト deploy-<repo> を作成
• データベースの製品／エンジン：曖昧でなければ、正確なエンジンを推定する（mysql -> rds/mysql、sqlserver -> rds/sqlserver）。PostgreSQL では、プロジェクトに RDS／AIDAP PostgreSQL／Supabase の明示的な選択を示す情報がない場合、AIDAP Supabase（database_product=aidap、database_engine=supabase）を選択する。
• リソース管理：references/deploy-mode-heuristics.md を適用する

ユーザーが既存リソースの再利用を選んだ場合は、その方式で必要なリソース ID だけを尋ねてください。再利用したリソースは、クリーンアップ時に破棄してはいけません。

---

5. ユーザーの選択を記録するのは、役立つ場合に限ります

同じ会話内で実行を続ける場合、ファイルは不要です。ユーザーが後で再開する可能性がある場合や、次のステップで永続的な引き継ぎが必要な場合は、小さな選択記録のみを書き込みます。

{
  "schema_version": "1",
  "repo_dir": "/absolute/path",
  "repo_name": "my-app",
  "git_sha": "abc1234",
  "region": "cn-beijing",
  "mode": "ecs",
  "port": 8080,
  "dependencies": ["postgresql", "redis"],
  "database_product": "aidap",
  "database_engine": "supabase",
  "resource_strategy": "create-isolated-project",
  "project": "deploy-my-app",
  "infra_management": "cli"
}

.volcengine/deploy-choice.json に書き込みます。

ユーザーがレポートを求めない限り、スコア表、根拠の配列、または完全な推奨マトリックスは書き込まないでください。

---

6. 要約テンプレート

Project detection:
- Runtime: <language>/<framework>
- Deployable surface: <surface or unclear, with evidence>
- Entrypoint/port: <entrypoint> / <port>
- Packaging signals: Dockerfile=<yes/no>, Compose=<yes/no>
- Dependencies: <deps or none>
- Database choice: <none | database_product=rds engine=mysql|postgresql|sqlserver | database_product=aidap engine=supabase|postgresql>
- Migrations: <paths or none>
- Resource management recommendation: <iac|cli>

Ranked order:
1. <mode>
   Reason: ...
   Tradeoff: ...
   Rough cost: ...

2. <mode>
   ...

3. <mode>
   ...

Please confirm:
1. Deployment mode: defaults to <first mode>
2. Resource strategy: defaults to a new isolated project deploy-<repo>; reuse is also possible
3. Resource management: recommend <iac|cli>; confirm `iac` or `cli`