Azv Diagram To Bicep

Generate Bicep templates and PowerShell deployment scripts from a Draw.io Azure architecture diagram.

Input: A Draw.io diagram file (.drawio or .drawio.xml) in the workspace. The user can specify the file path, or the skill will look for .drawio files in the workspace.

Tools required: File system tools (read/write files), Bicep MCP server (for best-practice validation)

Reference files:

• .github/skills/shared/azure-resource-model.md — Shared resource metadata model definition
• .github/skills/shared/azure-stencil-mapping.json — Azure resource type to Draw.io stencil mapping (used for reverse-lookup: image path → resource type)
• .github/skills/shared/azure-resource-configs.md — Per-resource-type configuration schemas and auto-detection rules
• .github/skills/shared/data/azure-property-paths.json — Azure Property Retrieval Mapping (MCP tools, CLI fallbacks, ARM JSON paths, defaults)
• .github/skills/shared/azure-deployment-verification.md — Pre-deployment verification rules (MUST run before presenting results)

Shared procedures (MUST follow):

• .github/skills/shared/bicep-best-practices.md — Bicep generation rules, defaults, and security settings (MUST read before generating Bicep)
• .github/skills/shared/version-currency.md — Version verification rules (MUST verify before generating code)
• .github/skills/shared/procedures/diagram-parsing.md — Diagram-to-resource-model parsing procedure

Steps

1. Accept Draw.io Diagram Input

Identify the Draw.io diagram to process.

If the user specifies a file path:

• Verify the file exists and is a .drawio or .drawio.xml file
• Read the file contents

If no file is specified:

• Search the workspace for .drawio files
• If exactly one is found, use it (announce which file)
• If multiple are found, present the list and ask the user to select one
• If none are found, ask the user to provide a diagram file

2. Parse Diagram into Resource Model

Follow the procedure in .github/skills/shared/procedures/diagram-parsing.md to parse the Draw.io XML into a structured resource model.

Display the parsed resource model as a table with columns: #, Resource, Type, Container, plus any connections.

3. Check for Existing Bicepparam File

Before generating new files, check if infrastructure already exists:

1. Look for a file named <diagram-name>.bicepparam in the same directory as the Draw.io file
2. If found: Load it, identify any new resources from the diagram not yet represented, and present a summary. Merge new parameters with the user's existing values preserved.
3. If not found: Proceed to generate everything fresh (Step 4)

4. Generate Bicep Templates and Bicepparam File

Generate and write each file to disk immediately as it is produced — do not accumulate file contents in memory or hold them for a combined response. Do not wait for user confirmation — the .bicepparam file is the user-editable configuration, and the user can modify it and redeploy at any time.

Critical — response verbosity rule: After writing each file, emit only a single confirmation line (e.g., ✓ Written: modules/networking.bicep). Do not echo file contents back into the response. This prevents hitting response length limits on complex diagrams.

Use the schemas defined in .github/skills/shared/azure-resource-configs.md for per-resource defaults and the rules in .github/skills/shared/bicep-best-practices.md for Bicep structure.

Output structure:

<solution-folder>/
├── main.bicep                    # Entry point — orchestrates all modules
├── <diagram-name>.bicepparam     # User-editable parameter values with comments
└── modules/
    ├── networking.bicep          # VNets, subnets, NSGs, peerings, private endpoints
    ├── compute.bicep             # VMs, App Services, Container Apps
    └── data.bicep                # SQL, Cosmos DB, Storage, Key Vault

Bicep generation rules:

1. main.bicep:

   • targetScope = 'resourceGroup'
   • Declare all parameters with @description() decorators explaining each setting
   • Include @allowed() where a fixed set of values applies (e.g., environment names)
   • Use default values on parameters where a sensible default exists
   • Mark sensitive parameters with @secure() (passwords, keys, connection strings)
   • Module references for each category — omit the name field on module blocks
   • Outputs for key resource IDs and endpoints

2. Module files (networking.bicep, compute.bicep, data.bicep):

   • Only generate modules that have resources (skip empty categories)
   • Use parent: property for child resources (e.g., subnets under VNet) — never / in name
   • Add existing resource blocks when referencing a parent not declared in the same file
   • Use symbolic references (foo.id) instead of resourceId()
   • Use secure defaults: httpsOnly: true, minimumTlsVersion: '1.2', publicNetworkAccess: 'Disabled' where private endpoints exist
   • Use user-defined types instead of open array/object where appropriate

3. <diagram-name>.bicepparam:

   • using 'main.bicep'
   • Include all parameter values
   • Add comments above each parameter or group explaining:
     • What the setting controls in plain language
     • 2-3 common alternatives with a one-line description
     • Cost impact where relevant (e.g., "$30/mo" vs "$140/mo")
     • Capacity/scaling consequences (e.g., "A /24 gives 251 usable IPs")
     • Security consequences where applicable
   • Use readEnvironmentVariable() for sensitive values (passwords, keys)
   • Keep each comment block to 1-3 lines — concise, not exhaustive

4. Parameter naming: Use camelCase, descriptive names (e.g., vmSize, appServicePlanSkuName, vnetAddressPrefix)

File write order (write and confirm each before moving to the next):

1. modules/networking.bicep (if networking resources exist)
2. modules/compute.bicep (if compute resources exist)
3. modules/data.bicep (if data resources exist)
4. Any additional module files (e.g., modules/identity.bicep, modules/monitoring.bicep)
5. main.bicep
6. <diagram-name>.bicepparam

Bicepparam comment guidelines:

using 'main.bicep'

// Azure region for all resources. Options: eastus, westeurope, westus2, northeurope
param location = 'eastus'

// VNet address space. /16 gives room for many subnets; /24 limits to ~251 hosts total.
param vnetAddressPrefixes = ['10.0.0.0/16']

// VM size — controls CPU, memory, cost.
//   Standard_B2s    → 2 vCPU, 4 GB  (~$30/mo) — dev/test
//   Standard_D2s_v3 → 2 vCPU, 8 GB  (~$70/mo) — general workloads
//   Standard_D4s_v3 → 4 vCPU, 16 GB (~$140/mo) — heavier workloads
param vmSize = 'Standard_B2s'

Rules for defaults:

• Use cost-effective defaults (e.g., Standard_B2s for VMs, S1 for App Service Plans, Standard_LRS for Storage)
• Default region: eastus
• Enable secure defaults: HTTPS only, TLS 1.2 minimum, deny public access where private endpoints exist
• Do NOT default to production-scale settings — prefer dev/test sizing that can be scaled up
• Version currency — always verify runtime stacks, API versions, and OS images are current before using them (see "Version Currency" section above). Never blindly copy defaults from reference files without checking they are still current.