azure-app-onboard-prereq
Azure に載せる前に、手元のアプリのコードが載せられる状態かを読むだけで点検させる。ビルド・中身の欠け・載せ方の 3 つの軸で部品ごとに合否を付け、何が止めているかを出す
npx skills add microsoft/azure-skills/azure-app-onboard-prereq入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 160,146
- 実用度
- 75
- GitHub star
- 1,623
- 最終更新
- 2026/11/7
頼み方の例
そのままコピーして使えますazure-app-onboard-prereqスキルを使って、このリポジトリが Azure に載せられる状態かを点検してください。部品ごとの判定と、載せるのを止めている問題を重さの順に出してください。コードの修正はまだ行わないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
- ファイルを書き換える記述があります
- 実行可能なスクリプトが 2 件同梱されています（TypeScript）
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
この解説は再確認中です。 2026年11月7日に原本（SKILL.md）が更新されており、以下の解説が現在の内容と合っていない可能性があります。最新の内容は GitHub の SKILL.md を確認してください。
いつ使うか
Azure の設定を作り始める前に、アプリ自体に問題がないかを確かめたいときに効きます。「このアプリはそのまま Azure に載せられるか」「Dockerfile は要るか」「依存しているものは Azure で動くか」「載せるのを止めているものは何か」といった問いが対象です。
部品ごとに 3 つの軸で点検する
点検は、部品（フロントエンド、API など）ごとに 3 つの軸で行います。
- ビルドビルドが通る構成か（実際には動かさず、設定ファイルから読む）
- 中身の欠け動かすのに要るものがそろっているか
- 載せ方使っている技術が Azure で動くか、載せられる形か
判定は 6 段
判定は 6 段です。直せない穴がある（🛑）、大きな移行が要る（🔶、古い実行環境や他社クラウドの SDK など）、載せると失敗する（❌）、載るが直したほうがよい（🔧）、注意（⚠️）、問題なし（✅）。
ひとつでも ❌ があれば、全体は「止まっている」になります。
読むだけで、ビルドもテストも走らせない
本文の冒頭が「絶対の禁止」です。
例外は、このスキルが直したコードや一から書いたコードを確かめるときだけで、そのコマンドごとに利用者の同意を取る決まりです。「前にいいと言った」は同意に数えません。
8 段を省かずに通す
本文は「8 段を例外なく通せ」と決めています。個別の質問にも、途中で答えずに 5 段目の結果の中で答えます。
- 記録の確認作業の記録を作るか、前回の続きかを決める
- 中身を読む部品・既存の設定・他社クラウドの SDK を探す
- 部品ごとの点検ビルド・中身の欠け・載せ方の 3 軸
- 記録と判定結果を書き出してから全体の判定を出す
- 結果を見せる重い順にまとめて出す
- 直す❌ や 🔧 があるときだけ。確認を取ってから
- 最後の記録点検した時点のコミットを残す
- 次へ回す次のスキルへ回すかを決める
使わないほうがいいとき
Azure の設定ファイルを点検したいとき
Bicep、Terraform、azure.yaml の点検は、本文が azure-validate を案内しています。
Azure の設定ファイルを作りたいとき
azure-prepare の担当です。
他社のクラウドから移したいとき
他社クラウドの SDK を使っていると分かった時点で、azure-cloud-migrate に回すかを聞きます。移さずに点検を続けても、SDK を差し替えるまでは次の段に進みません。
注意点
解析で見つかった記述と同梱ファイル
SKILL.md の解析では、シェルコマンドの実行とファイルの書き換えの記述が見つかっています。同梱ファイルは 15 件で、3 つの軸の点検の手順、判定の決まり、修正の手順などです。
TypeScript のファイル 2 件（prereq-schemas.ts と session-schemas.ts）は、記録の形式を決めた型の定義です。
リポジトリの中に作業の記録を作ります
.copilot-azure/sessions/ の下に、点検の結果（context.json、prereq-output.json、readiness-report.md）を書き出します。コミットに混ぜたくなければ、.gitignore に足してください。前回の記録が残っていると、続きから再開するか聞かれます。
4 段の流れの 1 段目です
本来は、同じ公開元の azure-app-onboard が全体を仕切る流れの最初の段で、単体でも呼べる作りになっています。呼ばれ方で、点検が済んだあとの動きが変わります。
仕切り役から呼ばれた場合
点検が済むと確認なしで次の段（設計）に進みます
単体で呼んだ場合
次に進むかを聞いて止まります
足りない CLI を入れる道具を使う
本文の MCP の道具の表には、az・azd・func の有無を確かめて入れる道具（mcp_azure_mcp_extension_cli_install）が載っています。手元の環境に CLI が増えることがあります。
修正は許可制です
❌ や 🔧 が出ると、直す手順に入ります。コードを書き換える前には必ず確認を取り、結果を出すまでの質問は 3 つまでと決めています。
インストール数
インストール数は約 8.3 万件です。同じリポジトリの 28 件は約 8 万〜57 万件で、2 つの塊に分かれています（2026-09-07 の上流集計）。この公開元のスキルの関係は Azure のスキル群の地図にまとめています。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
まだコードが無くても使えますか
使えます。プロジェクトのファイルも Dockerfile も index.html も無ければ、コードが無い場合の手順に切り替わり、一から組み立てる道を案内します。
1 つのリポジトリに複数のアプリがあります
プロジェクトの定義ファイルが複数あれば、部品の対応付けの資料を読んで、部品ごとに判定します。技術の判定が食い違ったときは、利用者が明言したものを優先し、推測だけのときは確かめてから進みます。
どんな問題が「直せない」判定になりますか
資料の定義では、🛑 は「アプリがわざと脆弱に作られている」場合です。直す手段が無いものとして、流れ全体を止めます。
点検したあとにコードを変えたらどうなりますか
点検の最後に、その時点のコミット（git rev-parse HEAD）を記録します。続きから再開するときにいまのコミットと比べ、変わっていれば点検の結果が古いと判断します。