AutoGineer
Generated banner for Azure Enterprise Infra Planner
Generated logo for Azure Enterprise Infra Planner

Azure Enterprise Infra Planner

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Cloud and DevOps
  • MIT
  • No issues found
Download ZIP

From the author

Architect and provision enterprise Azure infrastructure from workload descriptions. For cloud architects and platform engineers planning networking, identity, security, compliance, and multi-resource topologies with WAF alignment. Generates Bicep or Terraform directly (no azd). WHEN: 'plan Azure infrastructure', 'architect Azure landing zone', 'design hub-spoke network', 'plan multi-region DR topology', 'set up VNets firewalls and private endpoints', 'subscription-scope Bicep deployment', 'Azure Backup for VM workloads'. PREFER azure-prepare FOR app-centric workflows.
— the description by Microsoft

AutoGineer summary

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

This skill guides users through a 7-phase pipeline to design and deploy Azure infrastructure. It processes workload descriptions to generate Bicep or Terraform code, supporting both greenfield deployments and additive updates to existing environments. The process includes research, planning, user approval, and automated validation using security and syntax checks before deployment.

What it does

  • Extracts insights from workload descriptions to inform infrastructure planning.
  • Researches Azure best practices and service-specific documentation.
  • Generates infrastructure plans and corresponding Bicep or Terraform code.
  • Validates generated IaC using syntax checks and security scanning tools.
  • Supports additive deployments for existing environments without modifying referenced resources.
  • Manages multi-resource topologies including networking, identity, and compliance configurations.

When to use it

  • When planning Azure infrastructure from a workload or architecture description.
  • When designing hub-spoke networks, landing zones, or multi-region topologies.
  • When setting up networking components like VNets, firewalls, and private endpoints.
  • When generating subscription-scope or multi-resource-group infrastructure code.

Advantages

  • Follows a structured, gated pipeline to ensure plan approval and code validation.
  • Integrates security scanning and syntax validation into the generation workflow.
  • Provides support for referencing existing resources to avoid accidental recreation.
  • Utilizes specific Azure schema data to ensure accurate resource definitions.

Usage examples

“Plan Azure infrastructure for a hub-spoke network with firewalls.”
The agent initiates the 7-phase pipeline, researching networking best practices and generating the corresponding IaC for the requested topology.
“Architect an Azure landing zone.”
The agent guides the user through requirements extraction and resource planning, resulting in a structured infrastructure plan and Bicep or Terraform files.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/azure-enterprise-infra-planner/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip azure-enterprise-infra-planner.zip -d .agents/skills

Documentation by Microsoft

Azure Enterprise Infra Planner

When to Use This Skill

Activate this skill when user wants to:

  • Plan enterprise Azure infrastructure from a workload or architecture description

  • Architect a landing zone, hub-spoke network, or multi-region topology

  • Design networking infrastructure: VNets, subnets, firewalls, private endpoints, VPN gateways

  • Plan identity, RBAC, and compliance-driven infrastructure

  • Generate Bicep or Terraform for subscription-scope or multi-resource-group deployments

  • Plan disaster recovery, failover, or cross-region high-availability topologies

Quick Reference

PropertyDetails
MCP toolsinsights_get, get_azure_bestpractices_get, wellarchitectedframework_serviceguide_get, microsoft_docs_fetch, microsoft_docs_search, bicepschema_get
CLI commandsaz deployment group create, az bicep build, az resource list, terraform init, terraform plan, terraform validate, terraform apply, checkov
Output schemaschema.md
Key referencesworkflow.md, waf-checklist.md, resources/, constraints/

Workflow (Start Here)

Follow the step-by-step instructions in workflow.md to execute the 7 phases of infrastructure planning and provisioning.

Architecture

The skill runs a 7-phase, gated pipeline. Input is triaged into one of two flows:

  • Greenfield — only new requirements; run the phases straight through.

  • Referenced (brownfield) — the user supplies something that already exists (a live resource / resource group / subscription, IaC or an infra plan, or a requirements doc). The same phases run, plus referenced-workload.md: existing resources are inventoried and referenced (never recreated), the new workload is wired into them, and Phase 7 deploys additively (incremental only — never modifying or destroying the referenced resources).

Every phase advances only after its gate passes. Phase 5 requires explicit user approval; Phase 6 is a hardened, self-verifying gate — the generated IaC must be secure-by-default, pass local validation (az bicep build / terraform validate) with zero errors, pass a checkov security scan with no unresolved high/critical findings, and the skill must show the command output and emit a completion self-check before advancing; Phase 7 requires an explicit, risk-acknowledged deploy confirmation.

flowchart TD
    IN([Input]) --> TRIAGE{Existing infra<br/>referenced?}
    TRIAGE -- "No (greenfield)" --> P1
    TRIAGE -- "Yes (referenced)" --> RW[/referenced-workload.md:<br/>inventory + assign roles<br/>reference, never recreate/]
    RW --> P1

    subgraph PIPE [7-phase gated pipeline]
        direction TB
        P1[Phase 1 · Extract insights] --> P2[Phase 2 · Research best practices]
        P2 --> P3[Phase 3 · Research resources]
        P3 --> P4[Phase 4 · Generate plan]
        P4 --> P5{Phase 5 · Verify<br/>user approves?}
        P5 -- "no" --> P4
        P5 -- "approved" --> P6[Phase 6 · Generate IaC]
        P6 --> VAL{Validate<br/>az bicep build /<br/>terraform validate}
        VAL -- "errors" --> P6
        VAL -- "clean" --> P7{Phase 7 · Deploy<br/>risk-ack confirm?}
    end

    P7 -- "greenfield" --> DEP[az deployment / terraform apply]
    P7 -- "referenced" --> DEPADD[Additive deploy · incremental only<br/>what-if preview · no destroy of<br/>referenced resources]
    DEP --> OUT([Deployed])
    DEPADD --> OUT

    classDef gate fill:#fff3cd,stroke:#d39e00,color:#000;
    classDef ref fill:#e2f0d9,stroke:#548235,color:#000;
    class P5,VAL,P7,TRIAGE gate;
    class RW,DEPADD ref;

Artifacts (written under <project-root>/): .azure/insights.json (Phase 1), .azure/infrastructure-plan.json (Phase 4, status draft→approved→deployed), and infra/main.bicep + infra/modules/* or infra/main.tf + infra/modules/** (Phase 6).

MCP Tools

ToolPurpose
insights_getRetrieve insights about the user's existing Azure environment to guide planning decisions
get_azure_bestpractices_getAzure best practices for code generation, operations, and deployment
wellarchitectedframework_serviceguide_getWAF service guide for a specific Azure service
microsoft_docs_searchSearch Microsoft Learn for relevant documentation chunks
microsoft_docs_fetchFetch full content of a Microsoft Learn page by URL
bicepschema_getBicep schema definition for any Azure resource type (latest API version)

Error Handling

ErrorCauseFix
MCP tool error or not availableTool call timeout, connection error, or tool doesn't existRetry once; fall back to reference files and notify user if unresolved
Plan approval missingmeta.status is not approvedStop and prompt user for approval before IaC generation or deployment
IaC validation failureaz bicep build or terraform validate returns errorsFix the generated code and re-validate; notify user if unresolved
Pairing constraint violationIncompatible SKU or resource combinationFix in plan before proceeding to IaC generation
Infra plan or IaC files not foundFiles written to wrong location or not createdVerify files exist at <project-root>/.azure/ and <project-root>/infra/; if missing, re-create the files by following workflow.md exactly

Files

references/referenced-workload.md

Referenced-Workload Handling (on-demand)

Read this when the user provides something that already EXISTS — a live Azure resource / resource group / subscription, IaC (Bicep/Terraform/ARM) or an infra plan, or a general doc describing current infrastructure/requirements. If the input is purely NEW requirements with nothing existing, it's greenfield — ignore this file and run the normal phases.

The switched-up flow (referenced mode)

  1. Confirm it's referenced. Does anything already exist (a resource group/subscription, IaC/plan, or a doc describing current resources)? If yes, use this flow.

  2. Inventory the existing resources from whatever was provided. Capture a COMPLETE inventory — every resource type, plus topology/relationships (VNet/subnet, private endpoints, identity bindings) and key configurations (SKU/tier, TLS version, public-access setting, region). Do not omit resources or invent ones that are not present:

    • Resource group / subscription → introspect (az resource list / az graph query) → real resources with resource IDs.

    • IaC / infra plan (Bicep/Terraform/ARM, infrastructure-plan.json, terraform show -json) → parse resource / existing / data blocks → logical resources.

    • General doc → extract any existing resources it mentions.

  3. Gather insights from ALL provided context. Mine every input the user gave — docs, IaC comments, resource tags, requirements, naming conventions, region, resiliency tier, PADU/preferences, cost and compliance constraints — and record them as insights (the same channel Phase 3 already applies). These shape the new workload just like tenant insights do.

  4. Surface them and ask which to incorporate. Present the existing resources you found and ask which ones to incorporate (reference + wire) into the new workload. Recommend a sensible default — incorporate the ones the new workload clearly depends on; never recreate them.

  5. Generate the complete IaC incorporating the chosen (or recommended-default) existing resources: reference them (existing / data, real ID for live, a param otherwise) and wire the new resources to them, honoring the gathered insights. Never emit a new resource for something that already exists.

Answer-first (ask AND generate — never stall)

Open with a plain-language summary of the existing infrastructure you inventoried and the additive change you understood, then an explicit confirmation checkpoint ("Confirm this understanding before I proceed to deploy"), and then generate the complete, deployable IaC in the SAME response using the recommended default. Order within the turn: (1) summary of what exists + what you'll add, (2) explicit "confirm before I proceed" gate, (3) the generated IaC, (4) the "which to incorporate?" choice and any assumptions. Never end a turn with only a summary or a question, and never deploy before the user confirms. If you lack a value (region, an existing resource's ID/name), declare a parameter and proceed. The confirmation gate governs deployment (Phase 7), not whether you generate the plan/IaC — you always generate; you never deploy without an explicit, risk-acknowledged go-ahead.

Inputs (three shapes → one normalized inventory)

ShapeInputsReferencing precision
Actual statea live Azure resource, resource group, or subscriptionreal resource IDs → reference exactly (existing/data)
Declared stateBicep / Terraform / ARM, or an infra plan (infrastructure-plan.json, terraform show -json)logical → reference by parameter (or build, if it's a spec)
Requirements/contextany general doc with info/requirements the user wantsmine for requirements + any existing-resource mentions

Inputs can combine (e.g. a resource group + a requirements doc). If a declared file is ambiguous ("reference existing vs. build new?"), make the most likely assumption, state it, and generate — ask at most one question, after the code.

For each existing resource, assign a ROLE (the "if needed" filter)

  • Reference + integrate — the new workload depends on it → reference it AND wire it in: RBAC role assignment, diagnostics → existing Log Analytics, private endpoints into the existing VNet/subnet, secrets from the existing Key Vault, connection to the existing Event Hubs, use the existing managed identity, etc.

  • Retain — keep, must not recreate, nothing new connects → leave it; note "retained, out of scope".

  • Ignore — irrelevant → omit.

Never emit a new resource for a resource that already exists. Reference it.

Deploy (referenced mode)

Referenced mode does not skip Phase 7 — the deliverable is deployed new infrastructure that integrates with what already exists. Run phases/7-deploy.md with these guardrails:

  • Same destructive-action gate. Present the risks and require an explicit, risk-acknowledged "deploy" reply sent after the risks are shown. The original prompt never satisfies the gate.

  • Additive only. The deployment must add the new resources and their wiring. The referenced resources are declared as existing/data (not resource), so a normal deploy never touches them.

  • Incremental mode, never Complete. For Bicep use the default incremental mode — never --mode Complete (it would delete resources absent from the template, including the referenced ones). For Terraform, the referenced resources are data sources / imported, so apply must show no destroy against them — abort if the plan proposes destroying or replacing a referenced resource.

  • Preview first. Always run az deployment ... --what-if (Bicep) or terraform plan (Terraform) and confirm the diff only creates new resources and modifies nothing on the referenced ones before applying.

  • Deploy into the existing scope when integrating. Target the referenced resource group/subscription so RBAC, private endpoints, and diagnostics wire into the existing resources.

How this rides the existing phases

  • Phase 1: normalize the reference into insights.json — existing resources (real ID or param), must_not_recreate, integration points, requirements, tier.

  • Phase 3: existing "apply insights" logic assigns roles and picks references over new resources.

  • Phase 5: verify — (a) no duplicate of an existing resource; (b) every declared dependency on an existing resource is actually wired; (c) cross-module outputs.X you consume is declared by that module (prevents BCP053); (d) source unmodified.

  • Phase 6: emit new resources (secure-by-default) + existing/data references + the wiring. Real ID inline for actual-state; a param for declared/doc inputs.

  • Phase 7: DO NOT skip deploy — run Phase 7 like greenfield, honoring the destructive-action gate. The difference is scope: deploy only the new resources and their wiring; never modify, recreate, or destroy the referenced/existing resources. See "Deploy (referenced mode)" below.

Secure-by-default (Phase 6)

Private endpoints + publicNetworkAccess: Disabled on data services; managed identity over keys; storage allowSharedKeyAccess: false; Key Vault soft-delete + purge protection; AKS managed identity + disable local accounts; minimum TLS 1.2.

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.

Security

No issues found by our static scan· No issues found

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-enterprise-infra-planner · 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-enterprise-infra-planner.zip