Generated banner for Azure App Onboard
Generated logo for Azure App Onboard

Azure App Onboard

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Cloud and DevOps
  • MIT
  • Low risk
  • Has scripts

From the author

End-to-end orchestrator: from a business idea, app idea, or existing app to running Azure deployment with cost estimates and pre-deploy approval. Analyzes your app, auto-detects the right Azure services, scaffolds infrastructure code, and deploys — tailored to your app, not a template. Handles moving existing apps to Azure without rewriting or with minimal changes. WHEN: bring your app to Azure, plan my app, cost to run, is my code ready to deploy, deploy my app to the cloud, deploy all my services, what Azure services do I need, plan my Azure deployment, deploy my new app to Azure, one-click deploy, I have an app and want it on Azure, migrate my app to Azure, help me get started, build an app, no code yet, starter project. DO NOT USE FOR: use azd for deployment(use azure-deploy), optimizing existing costs (use cost-optimization), code readiness checks only (use azure-app-onboard-prereq).
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Azure App Onboard is a comprehensive workflow agent designed to take a business idea or an existing codebase and transition it to a running Azure deployment. It automates the entire lifecycle from initial discovery and architecture planning to infrastructure scaffolding and final deployment. The skill is built to be intelligent and tailored, analyzing the specific requirements of your application rather than relying on generic templates. It includes built-in approval gates for both the architecture plan and the final deployment, ensuring you maintain control over costs and resource configuration throughout the process.

What it does

  • Analyzes your application code or business idea to determine the optimal Azure service stack.
  • Generates custom infrastructure-as-code (IaC) files tailored to your specific application needs.
  • Provides detailed cost estimates for the proposed Azure infrastructure before deployment.
  • Executes the deployment of resources directly to your Azure subscription.
  • Handles the migration of existing applications to Azure with minimal code changes.
  • Provides a structured, step-by-step onboarding experience for developers of all experience levels.

When to use it

  • When you have an application and want to deploy it to Azure but are unsure which services to use.
  • When you need to migrate an existing application to the cloud without a complete rewrite.
  • When you require a cost estimate for your infrastructure before committing to a deployment.
  • When you need guided, end-to-end assistance for setting up a new Azure project.
  • When you want to verify if your current codebase is ready for a cloud deployment.

Advantages

  • Eliminates guesswork by auto-detecting the right Azure services for your specific stack.
  • Reduces manual effort by automating the scaffolding of infrastructure-as-code.
  • Ensures transparency with mandatory approval gates for architecture and deployment.
  • Provides cost visibility early in the planning phase.
  • Supports a wide range of scenarios from greenfield projects to existing app migrations.

Usage examples

“I have a Python web app and want to deploy it to Azure. Can you help me get started?”
The agent will initiate the discovery phase, scan your codebase, propose an architecture, and guide you through the deployment process.
“I need to move my existing application to Azure, but I'm not sure what services I need. Can you plan this for me?”
The agent will analyze your app's requirements, suggest the appropriate Azure services, and provide a cost estimate for your approval.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/azure-app-onboard/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip azure-app-onboard.zip -d .agents/skills

Documentation by Microsoft

Azure App Onboard

⛔ Every repo goes through the full pipeline (Steps 1–10). No exceptions. Do not skip steps, refuse, or short-circuit based on what you recognize. Follow the Workflow table below sequentially — read each step's references before acting.

Quick Reference

PropertyValue
Best forDevelopers who know what to build but not which Azure services to use
InputsBusiness idea or existing codebase, budget/scale preferences (optional)
OutputsArchitecture plan, cost estimate, IaC files, deployed Azure resources
PhasesDiscover → Architect → Scaffold → Deploy (self-contained, no external skill calls)

When to Use This Skill

  • Deploy existing code without knowing which Azure services to use

  • Check if your existing code is ready to deploy to Azure

  • Move an existing app to Azure without rewriting or with minimal changes

  • Get cost estimates before committing to infrastructure

  • Understand architecture decisions and rejected alternatives

  • Get answers to Azure architecture or service selection questions (e.g., "What database should I use?")

  • Get guided Azure onboarding without prior experience

When NOT to Use

ScenarioUse Instead
Run azd up or execute an existing deploymentazure-deploy
Optimize existing Azure spendcost-optimization from the optional azure-cost plugin
Generate Bicep/Terraform for a known architectureazure-prepare
Validate infrastructure or run preflight checksazure-validate
Troubleshoot a running Azure deploymentazure-diagnostics
Deploy to or manage AKS/Kubernetes directlyazure-kubernetes
Look up or list existing Azure resourcesazure-resource-lookup

If cost-optimization is unavailable, explain that it is provided by the optional azure-cost plugin and direct the user to their client's supported plugin installation flow; do not imply the handoff completed.

Pipeline Rules

⛔ You MUST read references/pipeline-rules.md at the start of every AppOnboard session. It contains approval gates, phase lifecycle, session artifacts, deploy-as-is, and security baseline rules.

Workflow

⛔ Deploy recovery: After deploy gate approval OR before any az deployment/az webapp deploy/az acr build — if you haven't read deploy/PHASE.md, read .copilot-azure/sessions/{id}/deploy-checklist.md first, then deploy/PHASE.md. ⛔ NEVER invoke {"skill": "azure-deploy"} — that is a DIFFERENT skill for a DIFFERENT workflow.

⛔ Post-scaffold transition (MANDATORY): Immediately after scaffold-manifest.json is written, YOUR NEXT ACTION MUST be Step 8 (Deploy Approval Gate) — NOT a summary report, NOT a "here are the generated files" message, NOT a completion signal. Confirm context.json has completedPhases: [...,"scaffold"] + currentPhase: "deploy" (update it yourself if the scaffold subagent didn't). Re-read approval-gates.md § Deploy Gate if evicted from context (scaffold reference loading is heavy), then present the exact prompt: "🚀 Ready to deploy? (Yes / Run manually / Edit plan / Cancel)". This gate is the LAST content in your response — wait for the user's reply.

#StepActionReference
1Session check + Azure loginCreate/resume session, verify Azure CLI auth, resolve subscription + user identity⛔ You MUST read session-protocol.md
2Scope triageCheck azd markers, triage question. Empty workspace or code-only (no infra) → Step 3 directly.⛔ Read intent-gathering.md § Scope Triage
3Prereq scan⛔ Skip if completedPhases includes "prereq". Otherwise: invoke {"skill": "azure-app-onboard-prereq"}. Write prereq-output.json, update context.json. Halt if: overallHealth: "blocked" OR routeToSkill set.
4Gather intentPresent prereq results, confirm stack + Azure services, ask remaining questions.⛔ Read intent-gathering.md § After Prereq Returns
5Plan architectureWrite prepare-plan.json.⛔ You MUST read prepare/PHASE.md
6Scaffold approval gateDisplay plan for user approval BEFORE generating any files.⛔ Read approval-gates.md § Scaffold Gate
7ScaffoldGenerate IaC, self-review. Write scaffold-manifest.json. Update context.json.⛔ You MUST read scaffold/PHASE.md
8Deploy approval gateDisplay validation summary. ⛔ After approval: FIRST read deploy-checklist.md → deploy/PHASE.md. NEVER {"skill": "azure-deploy"}.⛔ Read approval-gates.md § Deploy Gate
9DeployExecute IaC, health-check. Write deploy-result.json.⛔ You MUST read deploy/PHASE.md
10HandoffSurface deployment identity, cleanup commands, next steps.⛔ You MUST read handoff-protocol.md

Error Handling

ErrorRemediation
Phase failsHalt, report phase + error. User decides: retry, skip, abort.
MCP server unavailableSkip affected checks, add disclaimer to costEstimate.assumptions[] and every approval gate.
Missing RBACReport required role + az role assignment command.

Shared references: MCP tools (cross-phase tool parameters) | IaC resources (Azure resource docs for troubleshooting)

Files

scaffold/PHASE.md

Azure App Onboard Scaffold — IaC Generation + Self-Review

Generate deployment-ready infrastructure code from an architecture plan, verify it with adversarial self-review, and bridge to validation — all without deploying.

Quick Reference

PropertyValue
Parentazure-app-onboard
Best forTurning prepare-plan.json service list into Bicep templates with secure-by-default patterns
Inputsprepare-plan.json (services, naming, quotas), context.json (overrides, components, repo info)
Outputsscaffold-manifest.json, generated IaC files in infra/
Pipeline positionPhase 3 of 4: prereq → prepare → scaffold → deploy
IaC formatBicep (v1 default). Terraform when existing .tf detected or user override.

When to Use This Skill

Invoked by the azure-app-onboard orchestrator at Phase 3 when prepare-plan.json exists with services[]. Not directly user-routable in v1.

Return to orchestrator: When complete, return control to azure-app-onboard. Do NOT directly invoke deploy — the orchestrator manages phase transitions.

When NOT to Use

ScenarioUse Instead
User-triggered IaC (no prepare-plan.json)azure-prepare
Subscription-scope landing zonesazure-enterprise-infra-planner
Execute deployment (azd up)azure-deploy (do NOT invoke from AppOnboard pipeline)

MCP Tools

See shared tools for cross-phase tools and global parameters. See scaffold tools for full parameter tables.

ToolSub-commandPurposeParameters
mcp_azure_mcp_bicepschemabicepschema_getARM resource type schemasresource_type (Required), api_version (Optional)
mcp_bicep_list_avm_metadata(flat)AVM module catalogNone
mcp_bicep_get_bicep_best_practices(flat)Bicep best practicesNone
mcp_bicep_get_az_resource_type_schema(flat)ARM resource type JSON schemaazResourceType, apiVersion (Required)
mcp_bicep_build_bicep(flat)Validate .bicep files (self-review L3)filePath (Required)
mcp_bicep_format_bicep_file(flat)Format .bicep files (LF enforcement)filePath (Required)
mcp_azure_mcp_deploydeploy_iac_rules_getIaC best practices and rulesdeployment-tool, iac-type, resource-types
mcp_azure_mcp_deploydeploy_pipeline_guidance_getCI/CD pipeline configis-azd-project, pipeline-platform, deploy-option
mcp_azure_mcp_get_azure_bestpracticesget_azure_bestpractices_getSDK/Functions best practicesresource, action
mcp_azure_mcp_azureterraformbestpractices(flat)Terraform patterns (TF path only)resource_type (Required)

Workflow

Session folder: .copilot-azure/sessions/{uuid}/ — reads prepare-plan.json + context.json, writes scaffold-manifest.json.

DETECT (Steps 1–4)
  1. Read prepare-plan.json — verify services[] exists, read naming config (especially naming.resourcePrefix, naming.suffix, naming.resources[]). Read resource group name from context.json.azure.resourceGroup. ⛔ Use EXACTLY these names in generated IaC — do NOT invent names, derive them from environmentName, or append your own suffixes. ⛔ Use EXACTLY the names from prepare-plan.json.naming.resources[] as Bicep parameters. Do NOT derive names with take(), substring(), or string manipulation. The plan is the source of truth. Missing → trigger prepare backfill via azure-app-onboard orchestrator.

  2. Read context.json — check overrides[] for iacFormat preference, detectedInfra[] for existing .tf, detectedInfraProvider for cloud provider classification.

  3. Check workspace for existing IaC — ⛔ Skip if context.json.overrides[] contains ignoreExistingInfra: true. Otherwise:

    • Azure IaC (.bicep, azure.yaml, .tf with azurerm): ask_user → "Start fresh" (rename infra/ to infra.bak/) or "Use existing" (route to azure-prepare, stop pipeline).

    • Non-Azure IaC (.tf with GCP/AWS): respect context.json.overrides[].iacFormat from prepare. Default: Bicep alongside existing TF.

    • Unknown TF (detectedInfraProvider.terraform == "unknown"): ask user which provider before routing.

    • No IaC: continue.

  4. Determine compute targets — Check which compute targets are in the plan (App Service/Functions, Container Apps, or both) and whether PostgreSQL/Redis is present. Do NOT read any reference files — pass this info to the sub-agent at Step 5. 4b. Pre-check API versions (main thread) — MCP tool access is unreliable in task agents — call these in the main thread before dispatching. Call mcp_bicep_list_az_resource_types_for_provider (or bicep-list_az_resource_types_for_provider) once per provider namespace in prepare-plan.json.services[] (e.g., Microsoft.Web, Microsoft.App, Microsoft.DBforPostgreSQL, Microsoft.Cache, Microsoft.KeyVault, Microsoft.ContainerRegistry). Extract the latest GA API version (no -preview) for each resource type. Build an apiVersions map and pass it to the IaC gen sub-agent at Step 5. Fallback: if MCP unavailable, run az provider show --namespace {ns} --query "resourceTypes[?resourceType=='{type}'].apiVersions[?!contains(@, 'preview')] | [0][0]" -o tsv per resource type — this filters to GA-only and picks the latest. Pass "MCP unavailable" only if both MCP AND CLI fail. Sub-agent still validates generated Bicep via az bicep build.

ACTION (Steps 5–12)

⛔ File boundary: NEVER modify files outside infra/, .copilot-azure/. Scaffold only writes files — no install/build commands.

⛔ Sub-agent delegation is MANDATORY for Steps 5, 6–9, and 10–12. Each step reads its subagent-*.md template, then dispatches a task call. Do NOT read any reference file not explicitly named in these steps.

⛔ Dispatch type: task ONLY — NEVER general-purpose. general-purpose leaks sub-agent context into the main thread, accelerating compaction and evicting the orchestrator workflow. task isolates sub-agent context.

⛔ How to dispatch — VERBATIM COPY required:

  1. view the subagent-*.md template file

  2. Your NEXT action MUST be a task tool call — not view, powershell, create, or ANY other tool

  3. The task prompt MUST contain the COMPLETE and UNMODIFIED template text. Copy the template between <<<TEMPLATE_START>>> / <<<TEMPLATE_END>>> delimiters exactly as shown below. Do NOT summarize, paraphrase, reword, or omit ANY part of it — the sub-agent needs every "Read [file]" and "Do:" instruction to produce correct output

  4. AFTER the template block, append the data sections (plan JSON, overrides, etc.)

Anti-pattern (causes regressions): Writing your OWN prompt that lists workflow steps or describes what to generate. The template already contains the complete workflow — your job is to COPY it, not rewrite it.

  1. IaC generation — ⛔ You MUST dispatch subagent-iac-gen.md as a task. ⛔ agent_type: "task" — NEVER "general-purpose".

    <<<TEMPLATE_START>>>
    {paste the ENTIRE content of subagent-iac-gen.md here — unmodified}
    <<<TEMPLATE_END>>>
    
    ## Data (appended by orchestrator)
    ### prepare-plan.json
    {full JSON}
    ### context.json.overrides
    {overrides array}
    ### prereq-output.json.buildRequirements
    {buildRequirements object}
    ### prereq-output.json.warnings[]
    {warnings array}
    ### Compute targets
    {App Service/Functions, Container Apps, or both + whether PostgreSQL/Redis present}
    ### apiVersions
    {map from Step 4b, e.g. {"Microsoft.KeyVault/vaults": "2023-07-01", ...} — or "MCP unavailable" if skipped}
    ### Working directory
    {absolute path}
    • Expect: IaC files written to infra/, file list returned for scaffold-manifest.json.files[]

    • The tag app-onboard-skill: 'true' MUST appear verbatim in generated Bicep.

5b. Deploy checklist (parallel with Step 5) — Dispatch as a task in parallel with the IaC gen subagent above. ⛔ agent_type: "task" — NEVER "general-purpose".

<<<TEMPLATE_START>>>
You are a deploy-checklist generator. Do NOT invoke any skills.

1. Read the deploy-checklist-template at: plugin/skills/azure-app-onboard/deploy/references/deploy-checklist-template.md
2. Fill in {placeholders} with real values from prepare-plan.json (appName, rgName, subscriptionId, sessionId).
3. Delete sections that don't apply to this deployment's compute target (e.g., remove App Service section for Container Apps deploys). The template section headers indicate which to delete.
4. Write the result to the session folder using the `create` tool. This file survives conversation compaction — deploy re-reads it after every long-running command.
<<<TEMPLATE_END>>>

## Data (appended by orchestrator)
### prepare-plan.json
{full JSON}
### Session path
{.copilot-azure/sessions/{uuid}/}
### Compute targets
{App Service, Container Apps, Static Web Apps, or combination}
  • Expect: deploy-checklist.md written to session folder. If this subagent fails, the validate subagent (Steps 10b–12.5) will catch the missing file.

6–9. Self-review — ⛔ You MUST dispatch subagent-review.md as a task. ⛔ agent_type: "task" — NEVER "general-purpose".

<<<TEMPLATE_START>>>
{paste the ENTIRE content of subagent-review.md here — unmodified}
<<<TEMPLATE_END>>>

## Data (appended by orchestrator)
### Generated IaC files
{full content of every .bicep/.tf file}
### prepare-plan.json (services, naming, deploymentVariables)
{relevant sections}
### prereq-output.json.warnings[]
{warnings array}
  • Expect: findings JSON → write to scaffold-manifest.json.selfReview

  • FLAGGED at L1/L3 → fix IaC before proceeding

VALIDATE → MANIFEST → APPROVE (Steps 10–12.5)

10a. Format IaC (main thread) — For each .bicep file in infra/ (including modules/): call mcp_bicep_format_bicep_file (or bicep-format_bicep_file) with { filePath: "<absolute path>" }.This enforces LF line endings via the bicepconfig.json written during IaC generation. Fallback: skip if unavailable.

10a-conf. Conformance gate (main thread — MANDATORY for Bicep) — ⛔ Skip this entire step when the scaffold emitted Terraform (infra/main.bicep absent) — these checks are Bicep-only (Terraform is syntax-validated via terraform validate in the validate subagent). Otherwise run the conformance script from this skill's scripts/ dir; it deterministically catches ARM-rejected values az bicep build can't (invalid Bicep values, wrong DB version, reserved DB login, enablePurgeProtection):

{scaffoldDir}/scripts/scaffold-conformance.ps1 -SessionPath ".copilot-azure/sessions/{uuid}" -InfraPath infra   # pwsh (preferred)
bash {scaffoldDir}/scripts/scaffold-conformance.sh ".copilot-azure/sessions/{uuid}" infra                       # bash (only if pwsh unavailable; needs jq for the plan-dependent checks)

⛔ Prefer the .ps1 when pwsh is available — it runs every check unconditionally. The .sh twin skips the plan-dependent checks (DB-VERSION-MATCH, SERVICES-COMPLETE, DB-NAME-PRESENT, WARN-FIXED) when jq is absent. ⛔ Any BLOCK failure → fix the IaC, re-run (max 3); never present the deploy gate with an open BLOCK. Run it here in the main thread — do NOT delegate to the validate subagent or hand-judge the result when a shell exists. Pass the JSON to the validate subagent for scaffold-manifest.json.conformance.

10b–12.5. Validation + manifest — ⛔ You MUST dispatch subagent-validate.md as a task. ⛔ agent_type: "task" — NEVER "general-purpose".

<<<TEMPLATE_START>>>
{paste the ENTIRE content of subagent-validate.md here — unmodified}
<<<TEMPLATE_END>>>

## Data (appended by orchestrator)
### IaC file paths
{list of generated files}
### Self-review findings (from Steps 6–9)
{findings JSON}
### prepare-plan.json
{full JSON}
### prereq-output.json.warnings[]
{warnings array}
### prereq-output.json.healthEndpoint
{detected health path string or null}
### Conformance result
{JSON from Step 10a-conf}
### Session path
{.copilot-azure/sessions/{uuid}/}
  • Expect: scaffold-manifest.json with validationResult, deploy checklist generated

  • Verify deploy-checklist.md exists (written at Step 5b) — if missing, create NOW from deploy-checklist-template.md. Verify deploy-result.json exists — if missing, create from deploy-schemas.ts.

  • ⛔ Verify context.json update (main-thread — do NOT delegate). Read .copilot-azure/sessions/{uuid}/context.json. If completedPhases does not include "scaffold" OR currentPhase is not "deploy", write it yourself via edit / create: append "scaffold" to completedPhases, set currentPhase to "deploy", update lastModifiedUtc to current UTC ISO 8601. This is a phase-boundary write required by pipeline-rules.md — do not skip it.

  • ⛔ Return to orchestrator for Step 8 (Deploy Approval Gate). YOUR NEXT ACTION MUST BE presenting the Deploy Gate per orchestrator SKILL.md — do NOT write a "summary of generated files" message, do NOT emit a completion report. The Deploy Gate prompt (🚀 Ready to deploy? ...) is the ONLY correct next output.

Self-Healing Loop

On validation failure → read scaffold-healing-rules.md (healing cadence, PLAN_LEVEL_CHANGE, artifact consistency). Do NOT pre-read.

Error Handling

  • Missing prepare-plan.json: trigger backfill via orchestrator.

  • Existing IaC: handled in DETECT Step 3.

  • MCP unavailable: fall back to reference patterns, flag as "unverified."

  • FLAGGED findings and healing exhaustion: see scaffold-healing-rules.md.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/azure-skills/skills/azure-app-onboard · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download azure-app-onboard.zip