Azure Architecture Autopilot
GitHubOfficialFirst committed by whoniiiiDistributed by GitHub
- Skill
- Workflow
- Cloud and DevOps
- MIT
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Azure Architecture Autopilot is a multi-phase agentic workflow designed to assist users in creating or modifying Azure infrastructure. It guides users through an interactive design process, generates architecture diagrams using an embedded engine, produces Bicep templates, and manages the deployment lifecycle. The skill integrates with Azure services and utilizes official Microsoft documentation to ensure configurations align with current service specifications.
What it does
- Designs new Azure infrastructure based on natural language requirements.
- Analyzes existing Azure resources to generate visual architecture diagrams.
- Refines infrastructure designs through interactive conversation.
- Generates and reviews Bicep templates for infrastructure as code.
- Executes deployment workflows including validation and what-if analysis.
- Detects user language to provide localized support and documentation.
When to use it
- When you need to design a new Azure environment or RAG architecture.
- When you want to visualize your current Azure resource configuration.
- When you need to generate or update Bicep templates for Azure deployments.
- When you require guidance on modifying existing Azure infrastructure to meet new requirements.
Advantages
- Automated diagram generation using an embedded engine with official Azure icons.
- Structured multi-phase workflow ensuring design confirmation before deployment.
- Integration with Microsoft documentation for dynamic service property lookups.
- Supports natural language interaction for complex infrastructure tasks.
- Includes built-in safety checks like what-if analysis prior to deployment.
Usage examples
- “Create a RAG architecture on Azure.”
- The agent will initiate the design phase, suggest a baseline architecture, generate a diagram, and guide you through the Bicep generation and deployment process.
- “Analyze my current Azure infrastructure and draw a diagram.”
- The agent will scan your existing resources, infer relationships, and produce an interactive HTML diagram of your current setup.
- “I want to strengthen security for my existing Azure resources.”
- The agent will analyze your current configuration and propose modifications to your infrastructure design to align with security patterns.
Install
1 of its files are not mirrored here, so install it from its source:
https://github.com/github/awesome-copilot/tree/797337f33f73e35d08d82f840e21c4b8c4932d88/skills/azure-architecture-autopilot
Documentation by whoniiii
Azure Architecture Builder
A pipeline that designs Azure infrastructure using natural language, or analyzes existing resources to visualize architecture and proceed through modification and deployment.
The diagram engine is embedded within the skill (scripts/ folder).
No pip install needed — it directly uses the bundled Python scripts
to generate interactive HTML diagrams with 605+ official Azure icons.
Ready to use immediately without network access or package installation.
Automatic User Language Detection
🚨 Detect the language of the user's first message and provide all subsequent responses in that language. This is the highest-priority principle.
If the user writes in Korean → respond in Korean
If the user writes in English → respond in English (ask_user, progress updates, reports, Bicep comments — all in English)
The instructions and examples in this document are written in English, and all user-facing output must match the user's language
⚠️ Do not copy examples from this document verbatim to the user. Use only the structure as reference, and adapt text to the user's language.
Tool Usage Guide (GHCP Environment)
| Feature | Tool Name | Notes |
|---|---|---|
| Fetch URL content | web_fetch | For MS Docs lookups, etc. |
| Web search | web_search | URL discovery |
| Ask user | ask_user | choices must be a string array |
| Sub-agents | task | explore/task/general-purpose |
| Shell command execution | powershell | Windows PowerShell |
All sub-agents (explore/task/general-purpose) cannot use
web_fetchorweb_search. Fact-checking that requires MS Docs lookups must be performed directly by the main agent.
External Tool Path Discovery
az, python, bicep, etc. are often not on PATH.
Discover once before starting a Phase and cache the result. Do not re-discover every time.
⚠️ Do not use
Get-Command python— risk of Windows Store alias. Direct filesystem discovery ($env:LOCALAPPDATA\Programs\Python) takes priority.
az CLI path:
$azCmd = $null
if (Get-Command az -ErrorAction SilentlyContinue) { $azCmd = 'az' }
if (-not $azCmd) {
$azExe = Get-ChildItem -Path "$env:ProgramFiles\Microsoft SDKs\Azure\CLI2\wbin", "$env:LOCALAPPDATA\Programs\Azure CLI\wbin" -Filter "az.cmd" -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty FullName
if ($azExe) { $azCmd = $azExe }
}Python path + embedded diagram engine: refer to the diagram generation section in references/phase1-advisor.md.
Progress Updates Required
Use blockquote + emoji + bold format:
> **⏳ [Action]** — [Reason]
> **✅ [Complete]** — [Result]
> **⚠️ [Warning]** — [Details]
> **❌ [Failed]** — [Cause]Parallel Preload Principle
While waiting for user input via ask_user, preload information needed for the next step in parallel.
| ask_user Question | Preload Simultaneously |
|---|---|
| Project name / scan scope | Reference files, MS Docs, Python path discovery, diagram module path verification |
| Model/SKU selection | MS Docs for next question choices |
| Architecture confirmation | az account show/list, az group list |
| Subscription selection | az group list |
Path Branching — Automatically Determined by User Request
Path A: New Design (New Build)
Trigger: "create", "set up", "deploy", "build", etc.
Phase 1 (references/phase1-advisor.md) — Interactive architecture design + diagram
↓
Phase 2 (references/bicep-generator.md) — Bicep code generation
↓
Phase 3 (references/bicep-reviewer.md) — Code review + compilation verification
↓
Phase 4 (references/phase4-deployer.md) — validate → what-if → deployPath B: Existing Analysis + Modification (Analyze & Modify)
Trigger: "analyze", "current resources", "scan", "draw a diagram", "show my infrastructure", etc.
Phase 0 (references/phase0-scanner.md) — Existing resource scan + diagram
↓
Modification conversation — "What would you like to change here?" (natural language modification request → follow-up questions)
↓
Phase 1 (references/phase1-advisor.md) — Confirm modifications + update diagram
↓
Phase 2~4 — Same as aboveWhen Path Determination Is Ambiguous
Ask the user directly:
ask_user({
question: "What would you like to do?",
choices: [
"Design a new Azure architecture (Recommended)",
"Analyze + modify existing Azure resources"
]
})Phase Transition Rules
Each Phase reads and follows the instructions in its corresponding
references/*.mdfileWhen transitioning between Phases, always inform the user about the next step
Do not skip Phases (especially the what-if between Phase 3 → Phase 4)
🚨 Required condition for Phase 1 → Phase 2 transition:
01_arch_diagram_draft.htmlmust have been generated using the embedded diagram engine and shown to the user. Do not proceed to Bicep generation without a diagram. Completing spec collection alone does not mean Phase 1 is done — Phase 1 includes diagram generation + user confirmation.Modification request after deployment → return to Phase 1, not Phase 0 (Delta Confirmation Rule)
Service Coverage & Fallback
Optimized Services
Microsoft Foundry, Azure OpenAI, AI Search, ADLS Gen2, Key Vault, Microsoft Fabric, Azure Data Factory, VNet/Private Endpoint, AML/AI Hub
Other Azure Services
All supported — MS Docs are automatically consulted to generate at the same quality standard. Do not send messages that cause user anxiety such as "out of scope" or "best-effort".
Stable vs Dynamic Information Handling
| Category | Handling Method | Examples |
|---|---|---|
| Stable | Reference files first | isHnsEnabled: true, PE triple set |
| Dynamic | Always fetch MS Docs | API version, model availability, SKU, region |
Quick Reference
| File | Role |
|---|---|
references/phase0-scanner.md | Existing resource scan + relationship inference + diagram |
references/phase1-advisor.md | Interactive architecture design + fact checking |
references/bicep-generator.md | Bicep code generation rules |
references/bicep-reviewer.md | Code review checklist |
references/phase4-deployer.md | validate → what-if → deploy |
references/service-gotchas.md | Required properties, PE mappings |
references/azure-dynamic-sources.md | MS Docs URL registry |
references/azure-common-patterns.md | PE/security/naming patterns |
references/ai-data.md | AI/Data service guide |
assets/06-architecture-diagram.png | Example generated architecture diagram |
assets/07-azure-portal-resources.png | Example Azure portal resource view |
assets/08-deployment-succeeded.png | Example successful deployment result |
Files
- .gitignore508 B
- ATTRIBUTION.mdAdded by AutoGineer889 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md7.5 KiB
- assets/06-architecture-diagram.png326.8 KiB
- assets/07-azure-portal-resources.png171.4 KiB
- assets/08-deployment-succeeded.png41.0 KiB
- references/ai-data.md7.1 KiB
- references/architecture-guidance-sources.md6.9 KiB
- references/azure-common-patterns.md4.2 KiB
- references/azure-dynamic-sources.md4.7 KiB
- references/bicep-generator.md19.9 KiB
- references/bicep-reviewer.md7.1 KiB
- references/phase0-scanner.md24.9 KiB
- references/phase1-advisor.md46.9 KiB
- references/phase4-deployer.md11.7 KiB
- references/service-gotchas.md6.4 KiB
- scripts/cli.pyScript5.7 KiB
- scripts/generator.pyScript137.2 KiB
- scripts/icons.py(opens on GitHub)Not mirrored: opens on GitHub2.0 MiB
references/architecture-guidance-sources.md
Architecture Guidance Sources (For Design Direction Decisions)
A source registry for using Azure official architecture guidance only for design direction decisions.
The URLs in this document are a list of sources for "where to look". Do not hardcode the contents of these URLs as fixed facts. Do not use for SKU, API version, region, model availability, or PE mapping decisions — those are handled exclusively via
azure-dynamic-sources.md.
Purpose Separation
| Purpose | Document to Use | Decidable Items |
|---|---|---|
| Design direction decisions | This document (architecture-guidance-sources) | Architecture patterns, best practices, service combination direction, security boundary design |
| Deployment spec verification | azure-dynamic-sources.md | API version, SKU, region, model availability, PE groupId, actual property values |
What must NOT be decided using this document:
API version
SKU names/pricing
Region availability
Model names/versions/deployment types
PE groupId / DNS Zone mapping
Specific values for resource properties
Primary Sources
Targeted fetch targets for design direction decisions.
| ID | Document | URL | Purpose |
|---|---|---|---|
| A1 | Azure Architecture Center | https://learn.microsoft.com/en-us/azure/architecture/ | Hub — Entry point for finding domain-specific documents |
| A2 | Well-Architected Framework | https://learn.microsoft.com/en-us/azure/architecture/framework/ | Security/reliability/performance/cost/operations principles |
| A3 | Cloud Adoption Framework / Landing Zone | https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/ | Enterprise governance, network topology, subscription structure |
| A4 | Azure AI/ML Architecture | https://learn.microsoft.com/en-us/azure/architecture/ai-ml/ | AI/ML workload reference architecture hub |
| A5 | Basic Foundry Chat Reference Architecture | https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/basic-azure-ai-foundry-chat | Basic Foundry-based chatbot structure |
| A6 | Baseline AI Foundry Chat Reference Architecture | https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-openai-e2e-chat | Foundry chatbot enterprise baseline (including network isolation) |
| A7 | RAG Solution Design Guide | https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-solution-design-and-evaluation-guide | RAG pattern design guide |
| A8 | Microsoft Fabric Overview | https://learn.microsoft.com/en-us/fabric/get-started/microsoft-fabric-overview | Fabric platform overview and workload understanding |
| A9 | Fabric Governance / Adoption | https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-governance | Fabric governance, adoption roadmap |
Secondary Sources (awareness only)
Not direct fetch targets; referenced only for change awareness.
| Document | URL | Notes |
|---|---|---|
| Azure Updates | https://azure.microsoft.com/en-us/updates/ | Service changes/new feature announcements. Not a targeted fetch target |
Fetch Trigger — When to Query
Architecture guidance documents are not queried on every request. Only perform targeted fetch when the following triggers apply.
Trigger Conditions
When the user's workload type is identified in Phase 1 (automatic)
Pre-query the relevant workload's reference architecture to adjust question depth
Triggers automatically even if the user doesn't mention "best practice" etc.
Purpose: Reflect official architecture-based design decision points in questions, beyond SKU/region spec questions
When the user requests design direction justification
Keywords such as "best practice", "reference architecture", "recommended structure", "baseline", "well-architected", "landing zone", "enterprise pattern"
When architecture boundaries for a new service combination are ambiguous
Inter-service relationships that cannot be determined from existing reference files/service-gotchas
When enterprise-level security/governance design is needed
Subscription structure, network topology, landing zone patterns
When Triggers Do Not Apply
Simple resource creation (SKU/API version/region questions) → Use only
azure-dynamic-sources.mdService combinations already covered in domain-packs → Prioritize reference files
Bicep property value verification →
service-gotchas.mdor MS Docs Bicep reference
Fetch Budget
| Scenario | Max Fetch Count |
|---|---|
| Default (when trigger fires) | Architecture guidance documents up to 2 |
| Additional fetch allowed when | Conflicts between documents / core design uncertainty remains / user explicitly requests deeper justification |
| Simple deployment spec questions | 0 (no architecture guidance queries) |
Decision Rule by Question Type
| Question Type | Documents to Query | Design Decision Points to Extract | Documents NOT to Query |
|---|---|---|---|
| RAG / chatbot / Foundry app | A5 or A6 + A7 | Network isolation level, authentication method (managed identity vs key), indexing strategy (push vs pull), monitoring scope | Do not traverse entire Architecture Center |
| Enterprise security / governance / landing zone | A2 + A3 | Subscription structure, network topology (hub-spoke etc.), identity/governance model, security boundary | AI/ML domain documents not needed |
| Fabric data platform | A8 + A9 | Capacity model (SKU selection criteria), governance level, data boundary (workspace separation etc.) | AI-related documents not needed |
| Ambiguous service combination (unclear pattern) | A1 (find closest domain document from hub) + that document | Key design decision points identified from the document | Do not traverse all sub-documents |
| Simple resource creation values (SKU/API/region) | No query | — | All architecture guidance |
| General AI/ML architecture | A4 (hub) + closest reference architecture | Compute isolation, data boundary, model serving approach | Do not crawl entirely |
URL Fallback Rule
Use
en-usLearn URLs by defaultIf a specific URL returns 404 / redirect / deprecated → Fall back to the parent hub page
Example: If A5 fails → Search for "foundry chat" keyword on A4 (AI/ML hub)
If not found on the parent hub either → Search by title keyword on A1 (Architecture Center main)
Do not use the contents of a URL as fixed rules just because the URL exists
Full Traversal Prohibited
Do not broadly traverse (crawl) Architecture Center sub-documents
Only targeted fetch 1–2 related documents according to the decision rule by question type
Even within fetched documents, only reference relevant sections; do not read the entire document
Unlimited fetching, recursive link following, and sub-page enumeration are prohibited
Requirements and compatibility
Written for: GitHub Copilot
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· Low risk
- Phrasing that asks for actions without confirmation
- 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
- First committed by
whoniiii
- Publisher
- GitHub (Official)
- Distributed by
- GitHub
- Source
- github/awesome-copilot · skills/azure-architecture-autopilot · commit 797337f
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- whoniiii, NehaGitHubAcc, Sertxito, stbenjam
AutoGineer is not affiliated with or endorsed by whoniiii or GitHub.
Get it from the source
1 of this skill’s files are not mirrored here, so there is no ZIP. Get the complete skill from its source: github/awesome-copilot