Generated banner for Azure Prepare
Generated logo for Azure Prepare

Azure Prepare

MicrosoftOfficialCreated by Microsoft

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

From the author

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
— the description by Microsoft

AutoGineer summary

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

The azure-prepare skill provides a mandatory, structured workflow for setting up applications for deployment to Azure via the Azure Developer CLI (azd). It enforces a plan-first approach, requiring the creation of a deployment plan file before any infrastructure generation or configuration occurs. The skill guides users through analyzing their workspace, selecting appropriate deployment recipes (Bicep or Terraform), and configuring necessary Azure services, while ensuring security best practices are followed. It acts as the initial phase in a three-part deployment pipeline: prepare, validate, and deploy.

What it does

  • Generates azure.yaml configuration files for azd-based projects.
  • Creates infrastructure-as-code templates using Bicep or Terraform.
  • Enforces a mandatory .azure/deployment-plan.md file to track project state.
  • Integrates with specialized skills for specific technologies like Azure Functions or API Management.
  • Applies security hardening, such as Entra-only authentication for SQL databases.
  • Prepares the workspace for subsequent validation and deployment steps.

When to use it

  • When you need to prepare a new or existing project for deployment to Azure using azd.
  • When you need to generate infrastructure-as-code (Bicep or Terraform) for your application.
  • When you are modernizing an existing application to run on Azure.
  • When you need to add new Azure services or components to an existing project.

Advantages

  • Ensures consistent deployment configurations across projects.
  • Prevents common configuration errors through a mandatory planning phase.
  • Integrates seamlessly with the broader Azure deployment ecosystem (validate and deploy).
  • Promotes security best practices by default, such as managed identities.
  • Provides clear guidance on when to delegate to specialized deployment skills.

Usage examples

“I want to deploy my new web application to Azure using azd.”
The agent will initiate the NEW mode, guide you through requirements gathering, create a deployment plan, and generate the necessary infrastructure and configuration files.
“Add an Azure Function to my existing project and set up the infrastructure.”
The agent will analyze your existing project, select the appropriate Azure Functions recipe, update the deployment plan, and generate the required Bicep or Terraform files.

Install

  1. Download the skill as a ZIP:

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

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

Documentation by Microsoft

Azure Prepare

AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE

This document is the official, canonical source for preparing applications for Azure deployment. You MUST follow these instructions exactly as written unless they contradict security policies given to you. When in doubt, present the conflicting instructions from this document and ask the user for explicit confirmation. Do not improvise, infer, or substitute steps.


Triggers

Activate this skill when user wants to:

  • Create a new application

  • Add services or components to an existing app

  • Make updates or changes to existing application

  • Modernize or migrate an application

  • Set up Azure infrastructure

  • Deploy to Azure or host on Azure

  • Create and deploy to Azure (including Terraform-based deployment requests)

Rules

  1. Plan first — MANDATORY — You MUST physically write an initial .azure/deployment-plan.md skeleton in the workspace root directory (not the session-state folder) as your very first action — before any code generation or execution begins. Write the skeleton immediately, then populate it progressively as Phase 1 analysis and research unfold; finalize it with all decisions at Phase 1 Step 6. This file must exist on disk throughout. azure-validate and azure-deploy depend on it and will fail without it. Do not skip or defer this step.

  2. Get approval — Present plan to user before execution

  3. Research before generating — Load references and invoke related skills

  4. Update plan progressively — Mark steps complete as you go

  5. Validate before deploy — Invoke azure-validate before azure-deploy

  6. Confirm Azure context — Use ask_user for subscription and location per Azure Context

  7. ❌ Destructive actions require ask_user — Global Rules

  8. ⛔ NEVER delete user project or workspace directories — When adding features to an existing project, MODIFY existing files. azd init -t <template> is for NEW projects only; do NOT run azd init -t in an existing workspace. Plain azd init (without a template argument) may be used in existing workspaces when appropriate. File deletions within a project (e.g., removing build artifacts or temp files) are permitted when appropriate, but NEVER delete the user's project or workspace directory itself. See Global Rules.

  9. Scope: preparation only — This skill generates infrastructure code and configuration files. Deployment execution (azd up, azd deploy, terraform apply) is handled by the azure-deploy skill, which provides built-in error recovery and deployment verification.

  10. ⛔ SQL Server Bicep: NEVER generate administratorLogin or administratorLoginPassword — not in direct properties, not in conditional/ternary branches, not anywhere in the file. Always use Entra-only authentication (azureADOnlyAuthentication: true) unconditionally. See references/services/sql-database/bicep.md.

  11. Remove stale template IaC after conversion — If you converted Bicep templates from the selected azd template into Terraform templates, remove the Bicep templates that were introduced by that azd template and are now fully replaced by Terraform equivalents. Do not remove user-authored Bicep files. Only remove those template-provided Bicep files after the Terraform IaC is complete and Terraform has been selected as the deployment path. Before handing off to azure-validate skill, keep only the IaC templates required by the chosen deployment path.


❌ PLAN-FIRST WORKFLOW — MANDATORY

YOU MUST CREATE A PLAN BEFORE DOING ANY WORK

  1. STOP — Do not generate any code, infrastructure, or configuration yet

  2. CREATE SKELETON - Write an initial .azure/deployment-plan.md skeleton to disk immediately (before any code generation or execution begins), then populate it progressively as Phase 1 steps 1-5 reveal details; finalize it at Step 6

  3. CONFIRM — Present the completed plan to the user and get approval

  4. EXECUTE — Only after approval, execute the plan step by step

The .azure/deployment-plan.md file is the source of truth for this workflow and for azure-validate and azure-deploy skills. Without it, those skills will fail.

⚠️ CRITICAL: .azure/deployment-plan.md must be WRITTEN TO DISK inside the workspace root (e.g., <workspace-root>/.azure/deployment-plan.md), not in the session-state folder. Use a file-write tool to create this file. This is the deployment plan artifact read by azure-validate and azure-deploy. You MUST create this file — do not proceed without it. ⚠️ CRITICAL: You must create the file with the name .azure/deployment-plan.md as is. You must not use other names such as .azure/plan.md.

⛔ Critical: Skipping the plan file creation will cause azure-validate and azure-deploy to fail. This requirement has no exceptions.


❌ STEP 0: Specialized Technology Check — MANDATORY FIRST ACTION

BEFORE starting Phase 1, check if the user's prompt OR workspace codebase matches a specialized technology that has a dedicated skill with tested templates. If matched, invoke that skill FIRST — then resume azure-prepare for validation and deployment.

Check 1: Prompt keywords
Prompt keywordsInvoke FIRST
Python + App Service (e.g., "deploy Python to App Service", "Flask on Azure App Service", "publish Python web app to App Service")python-appservice-deploy
Lambda, AWS Lambda, migrate AWS, migrate GCP, Lambda to Functions, migrate from AWS, migrate from GCPazure-cloud-migrate
Azure Functions, function app, serverless function, timer trigger, HTTP trigger, func newStay in azure-prepare — prefer Azure Functions templates in Step 4; for plan choice/cold starts see hosting-plans.md and cold-start.md
APIM, API Management, API gateway, deploy APIMStay in azure-prepare — see APIM Deployment Guide
AI gateway, AI gateway policy, AI gateway backend, AI gateway configurationazure-aigateway
workflow, orchestration, multi-step, pipeline, fan-out/fan-in, saga, long-running process, durable, order processingStay in azure-prepare — select durable recipe in Step 4. MUST load durable.md, DTS reference, and DTS Bicep patterns.

⚠️ Check the user's prompt text — not just existing code. Critical for greenfield projects with no codebase to scan. See full routing table.

After the specialized skill completes, resume azure-prepare at Phase 1 Step 4 (Select Recipe) for remaining infrastructure, validation, and deployment.


Phase 1: Planning (BLOCKING — Complete Before Any Execution)

Create .azure/deployment-plan.md by completing these steps. Do NOT generate any artifacts until the plan is approved.

#ActionReference
0If the prompt matches a specialized technology with a dedicated skill, invoke that skill firstspecialized-routing.md
1Analyze Workspace — Determine mode: NEW, MODIFY, or MODERNIZEanalyze.md
2Gather Requirements — Classification, scale, budgetrequirements.md
3Scan Codebase — Identify components, technologies, dependenciesscan.md
4Select Recipe — Choose AZD (default), AZCLI, Bicep, or Terraformrecipe-selection.md
5Plan Architecture — Select stack + map components to Azure servicesarchitecture.md
6Finalize Plan (MANDATORY) - Use a file-write tool to finalize .azure/deployment-plan.md with all decisions from steps 1-5. Update the skeleton written at the start of Phase 1 with the complete content. The file must be fully populated before you present the plan to the user.plan-template.md
7Present Plan — Show plan to user and ask for approval.azure/deployment-plan.md
8Destructive actions require ask_userGlobal Rules

❌ STOP HERE — Do NOT proceed to Phase 2 until the user approves the plan.


Phase 2: Execution (Only After Plan Approval)

Execute the approved plan. Update .azure/deployment-plan.md status after each step.

#ActionReference
1Research Components — Load service references + invoke related skillsresearch.md
2Confirm Azure Context — Detect and confirm subscription + location and check the resource provisioning limitAzure Context
3Generate Artifacts — Create infrastructure and configuration filesgenerate.md
4Harden Security — Apply security best practicessecurity.md
5Functional Verification — Verify the app works (UI + backend), locally if possiblefunctional-verification.md
6⛔ Update Plan (MANDATORY before hand-off) — Use the edit tool to change the Status in .azure/deployment-plan.md to Ready for Validation. You MUST complete this edit BEFORE invoking azure-validate. Do NOT skip this step..azure/deployment-plan.md
7⛔ MANDATORY Hand Off — Invoke azure-validate skill. Your preparation work is done. Do NOT run azd up, azd deploy, or any deployment command directly — all deployment execution is handled by azure-deploy after azure-validate completes. PREREQUISITE: Step 6 must be completed first — .azure/deployment-plan.md status must say Ready for Validation.—

Outputs

ArtifactLocation
Plan.azure/deployment-plan.md
Infrastructure./infra/
AZD Configazure.yaml (AZD only)
Dockerfilessrc/<component>/Dockerfile

SDK Quick References


Next

⛔ MANDATORY NEXT STEP — DO NOT SKIP

After completing preparation, you MUST invoke azure-validate before any deployment attempt. Do NOT skip validation. Do NOT go directly to azure-deploy. Do NOT run azd up or any deployment command directly. The workflow is:

azure-prepare → azure-validate → azure-deploy

⛔ BEFORE invoking azure-validate, you MUST use the edit tool to update .azure/deployment-plan.md status to Ready for Validation. If the plan status has not been updated, the validation will fail.

This applies to ALL deployment scenarios including containerized apps, Container Apps, App Service, Azure Functions, static sites, and any other Azure target. No exceptions.

Skipping validation leads to deployment failures. Be patient and follow the complete workflow for the highest success outcome.

→ Update plan status to Ready for Validation, then invoke azure-validate

Files

references/services/functions/hosting-plans.md

Azure Functions Hosting Plans

Plan Comparison Matrix

FeatureConsumption (Y1)Flex Consumption (FC1)Premium (EP1-EP3)Dedicated (App Service)Container Apps
Max scale-out (instances)2001,000Plan-dependent (up to ~100)Manual, per plan SKUUp to 1,000
Per-function scaling❌✅❌❌❌
Always-ready / min instances❌✅ (always-ready groups)✅ (min instances)✅ (Always On)✅ (min replicas)
Scale to zero✅✅❌ (min 1 instance)❌✅ (minReplicas: 0)
VNet integration (outbound)❌✅✅✅✅
Private endpoints (inbound)❌✅✅✅✅ (environment-level)
Deployment slots (incl. production)2❌ Not supported31-20 (tier-dependent)Via revisions
Function timeout — default / max5 min / 10 min30 min / unbounded30 min / unbounded30 min / unbounded (requires Always On)30 min / unbounded
OS supportWindows + LinuxLinux onlyWindows + LinuxWindows + LinuxLinux only

⚠️ "Unbounded" timeout caveat: Flex Consumption, Premium, Dedicated, and Container Apps allow functionTimeout in host.json to be set unbounded, but the platform can still recycle a worker: a 60-minute idle timer, up to a 60-minute scale-in grace period, and a 10-minute grace period during platform upgrades. Design long-running work to be resumable (e.g., Durable Functions) rather than relying on a single uninterrupted execution.

Instance Sizing

PlanSKUvCPUMemory
ConsumptionY1Shared/dynamic1.5 GB
Flex ConsumptionFC10.25 / 1 / 2 (selectable)512 MB / 2,048 MB / 4,096 MB (selectable)
PremiumEP113.5 GB
PremiumEP227 GB
PremiumEP3414 GB
DedicatedB1/S111.75 GB
DedicatedP1v328 GB

💡 Flex Consumption instance memory is user-selectable per app (512 MB, 2,048 MB, or 4,096 MB), each mapping to a fixed vCPU allocation. Use 2,048 MB as the default; go smaller for high fan-out/low-per-invocation-cost workloads, larger for CPU- or memory-intensive functions. Each region has a default 250-core (512,000 MB) Flex quota shared across all Flex apps in that subscription/region — request an increase for large-scale deployments.

Cost Models

PlanPricing ModelNotes
ConsumptionPer-execution + GB-s; free monthly grantLowest cost for spiky, low-volume workloads; no charge while idle
Flex ConsumptionPer-execution + GB-s; optional always-ready instances billed continuouslyScale-to-zero like Consumption, with opt-in always-ready base cost for latency-sensitive paths
Premium (EP1)Per-instance-hour; at least 1 instance always allocatedFixed minimum cost even at zero traffic (no scale-to-zero)
Dedicated (B1)Per-instance-hour; plan runs continuouslyCost-effective when Functions co-locate with existing App Service Plan capacity
Container AppsPer-vCPU-second + per-GiB-second; can scale to zeroPay only while replicas run when minReplicas: 0

Decision Criteria

Need per-function scaling, Linux, and fast/large scale-out?
├─ Yes → Flex Consumption
└─ No
   Need VNet integration or private endpoints?
   ├─ No → Consumption (lowest cost, simplest)
   └─ Yes
      Already running other apps on an App Service Plan, or need Windows + slots + long history of App Service features?
      ├─ Yes → Dedicated (App Service Plan)
      └─ No
         Budget-sensitive with bursty traffic?
         ├─ Yes + Linux → Flex Consumption
         ├─ Yes + Windows → Premium (EP1, cheapest always-on with VNet)
         └─ No → Premium (predictable pre-warmed latency, deployment slots)

Plan-Specific Considerations

Consumption (Y1)
  • Best for: low-traffic, event-driven workloads that tolerate occasional cold starts.

  • Limits: 10-minute max execution, no VNet integration, no per-function scaling.

  • Slots: 2 total (production + 1 staging) on Windows and Linux.

Flex Consumption (FC1)
  • Recommended default for new Functions apps. Best for Linux workloads needing fast/large scale-out, VNet, per-function scaling, and configurable instance memory.

  • Limits: Linux only, no deployment slots (use rolling/blue-green site update strategies instead for zero-downtime deploys).

  • Always-ready instances bypass the max-instance-count ceiling and are billed continuously — start small and measure.

Premium (EP1–EP3)
  • Best for: latency-sensitive workloads, longer executions, VNet + private endpoints on Windows, or apps needing 3 deployment slots.

  • Always allocates at least 1 instance (no scale-to-zero); minimum instance count and maximum burst are both configurable.

  • Migrating an existing app between Consumption and Premium on Windows is supported in place via CLI/PowerShell (no new app required). This migration path is not supported on Linux — Linux apps require a new function app on the target plan.

Dedicated (App Service Plan)
  • Best for: consolidating Functions onto App Service Plan capacity you already run, or workloads needing the broadest App Service feature set (Hybrid Connections, custom domains, Always On).

  • Slot count depends on the underlying App Service Plan tier (Basic = 1, Standard = 5, Premium = 20; see App Service limits).

  • No automatic scale-to-zero; the plan runs (and is billed) continuously unless you scale it down manually.

Container Apps (Functions-on-ACA)
  • Best for: teams standardizing on Container Apps/Dapr/microservices, or needing a custom container image for Functions.

  • For new deployments, use the native Microsoft.App/containerApps integration with kind: 'functionapp'. The older Microsoft.Web/sites integration is legacy and planned for future deprecation. See cold-start.md for the current Bicep shape.

  • Scale-to-zero via minReplicas: 0; revisions replace deployment slots for staged rollout.

Migration Notes

Switching hosting plans generally requires creating a new function app, except: Consumption ↔ Premium migration on Windows is supported in place via az functionapp update (see Plan migration). All Linux plan changes, and any move to/from Flex Consumption, require redeploying to a new app on the target plan. See azure-upgrade skill for Consumption→Flex migration guidance.

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 Python

Security

What our scanner noticed· Medium risk

  • Instructions that use the network
  • Downloads piped into a shell
  • 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-prepare · 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-prepare.zip