azure-prepare
Azureアプリのデプロイ準備（Bicep/TerraformによるIaC、azure.yaml、Dockerfileの生成）を行うスキルです。アプリの新規作成・モダナイズ・デプロイを対象とし、Azure App ServiceやContainer Appsへのデプロイ、認証・キャッシュの追加、Managed IdentityやKey Vaultの設定など幅広いシナリオに対応します。クラウド間の移行にはazure-cloud-migrate、Copilot SDKアプリにはazure-hosted-copilot-sdkを使用してください。
description の原文を見る
Prepare Azure apps for deployment (infra Bicep/Terraform, azure.yaml, Dockerfiles). Use for create/modernize or create+deploy; not cross-cloud migration (use azure-cloud-migrate). DO NOT USE FOR: copilot-sdk apps (use azure-hosted-copilot-sdk). WHEN: \"create app\", \"build web app\", \"create API\", \"create serverless HTTP API\", \"create frontend\", \"create back end\", \"build a service\", \"modernize application\", \"update application\", \"add authentication\", \"add caching\", \"host on Azure\", \"create and deploy\", \"deploy to Azure\", \"deploy to Azure using Terraform\", \"deploy to Azure App Service\", \"deploy to Azure App Service using Terraform\", \"deploy to Azure Container Apps\", \"deploy to Azure Container Apps using Terraform\", \"generate Terraform\", \"generate Bicep\", \"function app\", \"timer trigger\", \"service bus trigger\", \"event-driven function\", \"containerized Node.js app\", \"social media app\", \"static portfolio website\", \"todo list with frontend and API\", \"prepare my Azure application to use Key Vault\", \"managed identity\".
SKILL.md 本文
Azure Prepare
権限ある指導 — 必須準拠
このドキュメントは、Azure へのデプロイメント用アプリケーション準備の公式かつ正規のソースです。与えられたセキュリティポリシーと矛盾しない限り、これらの指示に正確に従う必須があります。疑問な場合は、このドキュメントからの矛盾する指示を提示し、ユーザーに明示的な確認を求めてください。推測、推定、または手順の代替は行わないでください。
トリガー
ユーザーが以下を希望する場合、このスキルを有効化します:
- 新しいアプリケーションの作成
- 既存アプリへのサービスまたはコンポーネントの追加
- 既存アプリケーションへの更新または変更
- アプリケーションのモダナイズまたは移行
- Azure インフラストラクチャの設定
- Azure へのデプロイメントまたは Azure でのホスティング
- Azure への作成とデプロイメント (Terraform ベースのデプロイメント要求を含む)
ルール
- 最初に計画 — 必須 — ワークスペースルートディレクトリ (セッション状態フォルダではなく) に、コード生成または実行開始前の最初のアクションとして、初期
.azure/deployment-plan.mdスケルトンを物理的に書き込む必須があります。スケルトンをすぐに書き込み、Phase 1 の分析および調査が進むにつれて段階的に作成します。Phase 1 ステップ 6 で全決定を最終化します。このファイルは処理全体を通じてディスク上に存在する必須があります。azure-validate と azure-deploy はこれに依存し、なしでは失敗します。このステップをスキップまたは遅延させないでください。 - 承認を取得 — 実行前にユーザーに計画を提示
- 生成前に調査 — リファレンスをロードし、関連スキルを呼び出し
- 計画を段階的に更新 — 進むにつれてステップを完了としてマーク
- デプロイ前に検証 — azure-deploy 前に azure-validate を呼び出し
- Azure コンテキストを確認 —
Azure Contextに従いask_userを使用してサブスクリプションと場所を確認 - ❌ 破壊的なアクションには
ask_userが必須 —Global Rules - ⛔ ユーザープロジェクトまたはワークスペースディレクトリを削除しないでください — 既存プロジェクトに機能を追加する場合、既存ファイルを変更します。
azd init -t <template>は新規プロジェクト専用です。既存ワークスペースでazd init -tを実行しないでください。プレーンなazd init(テンプレート引数なし) は、適切な場合、既存ワークスペースで使用可能です。プロジェクト内のファイル削除 (ビルド成果物またはテンポファイルの削除など) は、適切な場合、許可されていますが、ユーザーのプロジェクトまたはワークスペースディレクトリそのものを削除しないでください。Global Rulesを参照してください。 - スコープ: 準備のみ — このスキルはインフラストラクチャコードと設定ファイルを生成します。デプロイメント実行 (
azd up、azd deploy、terraform apply) は、組み込みエラーリカバリとデプロイメント検証を提供する azure-deploy スキルで処理されます。 - ⛔ SQL Server Bicep:
administratorLoginまたはadministratorLoginPasswordを生成しないでください — 直接プロパティではなく、条件付き/三項分岐でもなく、ファイル内のどこにもありません。常に Entra のみの認証 (azureADOnlyAuthentication: true) を無条件で使用します。references/services/sql-database/bicep.mdを参照してください。 - 変換後のテンプレート IaC を削除 — 選択された
azdテンプレートから Bicep テンプレートを Terraform テンプレートに変換した場合、そのテンプレートによって導入され、現在 Terraform 等価物によって完全に置き換えられた Bicep テンプレートを削除します。ユーザー作成の Bicep ファイルは削除しないでください。Terraform IaC が完全で、Terraform がデプロイメントパスとして選択された後、そのテンプレート提供の Bicep ファイルのみを削除します。azure-validate スキルへの引き渡し前に、選択されたデプロイメントパスに必要な IaC テンプレートのみを保持します。
❌ 計画優先ワークフロー — 必須
作業を開始する前に計画を作成する必須があります
- 停止 — コード、インフラストラクチャ、または設定をまだ生成しないでください
- スケルトンを作成 - 初期
.azure/deployment-plan.mdスケルトンをディスクにすぐに (コード生成または実行開始前に) 書き込み、Phase 1 ステップ 1-5 により詳細が明らかになるにつれて段階的に作成します。ステップ 6 で最終化します- 確認 — 完成した計画をユーザーに提示し、承認を取得します
- 実行 — 承認後のみ、計画をステップバイステップで実行します
.azure/deployment-plan.mdファイルはこのワークフロー、および azure-validate と azure-deploy スキルの真実の情報源です。なしでは、これらのスキルは失敗します。⚠️ 重大:
.azure/deployment-plan.mdはワークスペースルート内のディスクに書き込まれる必須があります (例:/tmp/my-project/.azure/deployment-plan.md)。セッション状態フォルダではありません。ファイル書き込みツールを使用してこのファイルを作成します。これは azure-validate と azure-deploy で読み取られるデプロイメント計画成果物です。このファイルを作成する必須があります — これなしで進まないでください。 ⚠️ 重大: ファイルを.azure/deployment-plan.mdとして正確に作成する必須があります。.azure/plan.mdのような他の名前を使用しないでください。⛔ 重大: 計画ファイル作成をスキップすると、azure-validate と azure-deploy は失敗します。この要件に例外はありません。
❌ ステップ 0: 専門技術チェック — 必須最初アクション
Phase 1 を開始する前に、ユーザーのプロンプト OR ワークスペースコードベースが、テスト済みテンプレートを持つ専門スキルに一致するかどうかを確認します。一致する場合、最初にそのスキルを呼び出します — その後、検証とデプロイメント用に azure-prepare を再開します。
チェック 1: プロンプトキーワード
| プロンプトキーワード | 最初に呼び出し |
|---|---|
| Lambda、AWS Lambda、AWS からの移行、GCP からの移行、Lambda to Functions、AWS からの移行、GCP からの移行 | azure-cloud-migrate |
| copilot SDK、copilot アプリ、copilot 駆動、@github/copilot-sdk、CopilotClient | azure-hosted-copilot-sdk |
| Azure Functions、関数アプリ、サーバーレス関数、タイマートリガー、HTTP トリガー、func new | azure-prepare に留まる — ステップ 4 で Azure Functions テンプレートを優先 |
| APIM、API Management、API ゲートウェイ、APIM をデプロイ | azure-prepare に留まる — APIM Deployment Guide を参照 |
| AI ゲートウェイ、AI ゲートウェイポリシー、AI ゲートウェイバックエンド、AI ゲートウェイ設定 | azure-aigateway |
| ワークフロー、オーケストレーション、マルチステップ、パイプライン、ファンアウト/ファンイン、saga、長時間実行プロセス、durable、注文処理 | azure-prepare に留まる — ステップ 4 で durable レシピを選択。必須 durable.md、DTS reference、DTS Bicep patterns をロード。 |
チェック 2: コードベースマーカー (プロンプトが「Azure にデプロイ」のような一般的な場合も)
| コードベースマーカー | 場所 | 最初に呼び出し |
|---|---|---|
@github/copilot-sdk 依存関係内 | package.json | azure-hosted-copilot-sdk |
名前または依存関係内の copilot-sdk | package.json | azure-hosted-copilot-sdk |
CopilotClient インポート | .ts/.js ソースファイル | azure-hosted-copilot-sdk |
createSession + sendAndWait 呼び出し | .ts/.js ソースファイル | azure-hosted-copilot-sdk |
⚠️ ユーザーのプロンプトテキストを確認してください — 既存コードのみではなく。グリーンフィールドプロジェクト (スキャンするコードベースなし) に重要です。
完全ルーティングテーブルを参照してください。
専門スキル完了後、azure-prepare を Phase 1 ステップ 4 (レシピの選択) から再開して、残りのインフラストラクチャ、検証、およびデプロイメントを行います。
Phase 1: 計画 (ブロック — 実行前に完了)
以下のステップを完了して .azure/deployment-plan.md を作成します。計画が承認されるまで、成果物を生成しないでください。
| # | アクション | リファレンス |
|---|---|---|
| 0 | ❌ プロンプトとコードベースを専門技術でチェック — ユーザーが copilot SDK、Azure Functions などについて言及、または コードベースに @github/copilot-sdk が含まれている場合、最初にそのスキルを呼び出し | specialized-routing.md |
| 1 | ワークスペースを分析 — モードを決定: NEW、MODIFY、または MODERNIZE | analyze.md |
| 2 | 要件を収集 — 分類、スケール、予算 | requirements.md |
| 3 | コードベースをスキャン — コンポーネント、技術、依存関係を特定 | scan.md |
| 4 | レシピを選択 — AZD (デフォルト)、AZCLI、Bicep、または Terraform を選択 | recipe-selection.md |
| 5 | アーキテクチャを計画 — スタックを選択 + コンポーネントを Azure サービスにマップ | architecture.md |
| 6 | 計画を最終化 (必須) - ファイル書き込みツールを使用して .azure/deployment-plan.md をステップ 1-5 のすべての決定で最終化します。Phase 1 の開始時に書き込まれたスケルトンを完全なコンテンツで更新します。ユーザーに計画を提示する前に、ファイルは完全に入力されている必須があります。 | plan-template.md |
| 7 | 計画を提示 — ユーザーに計画を表示し、承認を求め | .azure/deployment-plan.md |
| 8 | 破壊的なアクションには ask_user が必須 | Global Rules |
❌ ここで停止 — ユーザーが計画を承認するまで Phase 2 に進まないでください。
Phase 2: 実行 (計画承認後のみ)
承認された計画を実行します。各ステップ後に .azure/deployment-plan.md ステータスを更新します。
| # | アクション | リファレンス |
|---|---|---|
| 1 | コンポーネントを調査 — サービスリファレンスをロード + 関連スキルを呼び出し | research.md |
| 2 | Azure コンテキストを確認 — サブスクリプション + 場所を検出して確認し、リソースプロビジョニング上限を確認 | Azure Context |
| 3 | 成果物を生成 — インフラストラクチャと設定ファイルを作成 | generate.md |
| 4 | セキュリティを強化 — セキュリティベストプラクティスを適用 | security.md |
| 5 | 機能検証 — アプリが動作するかを検証 (UI + バックエンド)、可能な場合はローカルで | functional-verification.md |
| 6 | ⛔ 計画を更新 (引き渡し前に必須) — edit ツールを使用して .azure/deployment-plan.md 内のステータスを Ready for Validation に変更します。azure-validate を呼び出す前にこの編集を完了する必須があります。このステップをスキップしないでください。 | .azure/deployment-plan.md |
| 7 | ⛔ 必須の引き渡し — azure-validate スキルを呼び出します。準備作業は完了です。azd up、azd deploy、またはデプロイメントコマンドを直接実行しないでください — すべてのデプロイメント実行は azure-deploy によって azure-validate 完了後に処理されます。前提条件: ステップ 6 を最初に完了する必須があります — .azure/deployment-plan.md ステータスは Ready for Validation である必須があります。 | — |
出力
| 成果物 | 場所 |
|---|---|
| 計画 | .azure/deployment-plan.md |
| インフラストラクチャ | ./infra/ |
| AZD 設定 | azure.yaml (AZD のみ) |
| Dockerfiles | src/<component>/Dockerfile |
SDK クイックリファレンス
- Azure Developer CLI:
azd - Azure Identity:
Python|.NET|TypeScript|Java - App Configuration:
Python|TypeScript|Java
次のステップ
⛔ 必須次のステップ — スキップしないでください
準備完了後、デプロイメント試行前に azure-validate を呼び出す必須があります。検証をスキップしないでください。azure-deploy に直接進まないでください。
azd upまたはデプロイメントコマンドを直接実行しないでください。ワークフローは以下の通りです:
azure-prepare→azure-validate→azure-deploy⛔ azure-validate を呼び出す前に、
editツールを使用して.azure/deployment-plan.mdステータスをReady for Validationに更新する必須があります。計画ステータスが更新されていない場合、検証は失敗します。これは、コンテナ化アプリ、Container Apps、App Service、Azure Functions、静的サイト、およびその他の Azure ターゲットを含むすべてのデプロイメントシナリオに適用されます。例外なし。
検証をスキップするとデプロイメント失敗につながります。忍耐強く完全なワークフローに従い、最高の成功結果を得てください。
→ 計画ステータスを Ready for Validation に更新し、azure-validate を呼び出します
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- microsoft
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/microsoft/azure-skills / ライセンス: MIT
関連スキル
agent-browser
AI エージェント向けのブラウザ自動化 CLI です。ウェブサイトとの対話が必要な場合に使用します。ページ遷移、フォーム入力、ボタンクリック、スクリーンショット取得、データ抽出、ウェブアプリのテスト、ブラウザ操作の自動化など、あらゆるブラウザタスクに対応できます。「ウェブサイトを開く」「フォームに記入する」「ボタンをクリックする」「スクリーンショットを取得する」「ページからデータを抽出する」「このウェブアプリをテストする」「サイトにログインする」「ブラウザ操作を自動化する」といった要求や、プログラマティックなウェブ操作が必要なタスクで起動します。
anyskill
AnySkill — あなたのプライベート・スキルクラウド。GitHubを基盤としたリポジトリからエージェントスキルを管理、同期、動的にロードできます。自然言語でクラウドスキルを検索し、オンデマンドでプロンプトを自動ロード、カスタムスキルのアップロードと共有、スキルバンドルの一括インストールが可能です。OpenClaw、Antigravity、Claude Code、Cursorに対応しています。
engram
AIエージェント向けの永続的なメモリシステムです。バグ修正、意思決定、発見、設定変更の後はmem_saveを使用してください。ユーザーが「覚えている」「記憶している」と言及した場合、または以前のセッションと重複する作業を開始する際はmem_searchを使用します。セッション終了前にmem_session_summaryを使用して、コンテキストを保持してください。
skyvern
AI駆動のブラウザ自動化により、任意のウェブサイトを自動化できます。フォーム入力、データ抽出、ファイルダウンロード、ログイン、複数ステップのワークフロー実行など、ユーザーがウェブサイトと連携する必要があるときに使用します。Skyvernは、LLMとコンピュータビジョンを活用して、未知のサイトも自動操作可能です。Python SDK、TypeScript SDK、REST API、MCPサーバー、またはCLIを通じて統合できます。
pinchbench
PinchBenchベンチマークを実行して、OpenClawエージェントの実世界タスクにおけるパフォーマンスを評価できます。モデルの機能テスト、モデル間の比較、ベンチマーク結果のリーダーボード提出、またはOpenClawのセットアップがカレンダー、メール、リサーチ、コーディング、複数ステップのワークフローにどの程度対応しているかを確認する際に使用します。
openui
OpenUIとOpenUI Langを使用してジェネレーティブUIアプリを構築できます。これらはLLM生成インターフェースのためのトークン効率的なオープン標準です。OpenUI、@openuidev、ジェネレーティブUI、LLMからのストリーミングUI、AI向けコンポーネントライブラリ、またはjson-render/A2UIの置き換えについて述べる際に使用します。スキャフォルディング、defineComponent、システムプロンプト、Renderer、およびOpenUI Lang出力のデバッグに対応しています。