Azure Deployment Preparation
Prepares azd-based Azure projects with deployment configuration, infrastructure code, and container files.
The document requires a deployment plan, user approval before execution, confirmation for destructive actions, no workspace deletion, managed identities, no hard-coded credentials, and Entra-only SQL authentication; it also defines the preparation/deployment handoff. However, the mandatory first-action write and broad tool/skill invocation create external effects, while permission scope, data-flow disclosure, and rollback guidance remain incomplete, so points are deducted.
The phased workflow, prerequisites, failure branches, and diagnostics are reasonably explicit, including Aspire, empty services, unsupported resource types, wrong subscriptions, and Functions secret storage. However, several referenced files, tools, and downstream skills are not present in the supplied evidence, trigger rules conflict with the main description, and key paths cannot be reproduced statically; the score therefore remains below the static ceiling.
The main description limits use to azd, while later triggers cover nearly any Azure application creation, modification, modernization, or deployment, creating false-trigger risk. Specialized routing is partly defined, but input/output contracts and non-fit boundaries are incomplete, with no stated Chinese-language or mainland-China network adaptation; points are deducted accordingly.
The skill has staged information architecture, progressive planning, artifact locations, MIT licensing, author and version metadata, extensive references, examples, and troubleshooting. It lacks a changelog and clearly assigned maintenance/update path, and dependency/tool installation guidance is incomplete, so it does not receive full marks.
It clearly defines expected artifacts and the azd-to-validation-to-deployment workflow, with useful security and verification checks. However, the supplied material omits the key templates and execution evidence needed to confirm directly usable generated output, so the score is limited near the static-review ceiling.
The README exposes CI/evaluation badges and documentation links, while the skill contains auditable rules, commands, and failure examples. It does not include concrete key-path test suites, pinned execution results, or independent corroboration for this skill, so only limited credit is awarded.
- The declared azd-only scope conflicts with the broader trigger list and may cause false activation; triggers should be narrowed.
- Mandatory workspace writing before user approval creates an external side effect; least privilege, rollback, and recovery should be made explicit.
- Referenced guidance files, MCP tools, and downstream skills are not included in the supplied evidence; their availability and version compatibility must be confirmed before deployment.
- Mainland-China reachability is not addressed; inaccessible Azure, documentation, or MCP services could block the core workflow.
What does this skill do, and when should you use it?
azure-prepare is for projects that explicitly use the Azure Developer CLI (azd), or already contain azure.yaml. It follows a plan-first workflow covering analysis, requirements, codebase scanning, recipe selection, architecture planning, and user approval. It can produce azure.yaml, Bicep or Terraform infrastructure, Dockerfiles, and a deployment plan at .azure/deployment-plan.md. It prepares deployments but does not execute azd up, azd deploy, or terraform apply.
The skill determines whether a workspace is new, being modified, or being modernized; gathers requirements; scans technologies and dependencies; selects AZD, AZCLI, Bicep, or Terraform; and maps application components to Azure services. During execution it can generate azure.yaml, infrastructure under infra/, and Dockerfiles under src/<component>/. It applies security constraints, supports functional verification, updates the plan to Ready for Validation, and hands the work to azure-validate. Its rules also cover Azure subscription and location confirmation, destructive actions, Entra-only SQL Server authentication, and removal of template-provided Bicep after a completed Terraform conversion.
- A developer wants to prepare a new application for Azure deployment with azd.
- A team has an existing azure.yaml and needs supporting Bicep, Terraform, or Dockerfile artifacts.
- A maintainer is adding Azure services and infrastructure to an existing application.
- A team is modernizing an application with Azure Functions, managed identity, or event-driven components.
- An infrastructure engineer wants a structured deployment plan to review before validation and deployment.
What are this skill's strengths and limitations?
- Defines a clear boundary between planning, approval, preparation, validation, and deployment.
- Covers common preparation artifacts including azure.yaml, Bicep, Terraform, and Dockerfiles.
- Provides concrete constraints for SQL Server credentials, destructive actions, and existing workspaces.
- Explicitly separates preparation from deployment handled by azure-deploy.
- It is intended for azd scenarios or projects that already use azure.yaml, not general non-azd deployments.
- The supplied source provides no independent test coverage or acceptance scenarios for this specific skill.
- Execution depends on external tools such as Azure CLI, azd, and Terraform, plus Azure subscription context.
- The required user-approval step requires adaptation for fully unattended automation.
How do you install this skill?
Install the repository collection with npx skills add microsoft/skills and select the required skill in the wizard. In Copilot CLI, run /plugin marketplace add microsoft/skills, then /plugin install azure-skills@skills. The source does not document a separate installation command for azure-prepare alone.
How do you use this skill?
Trigger it when the user explicitly requests azd-based preparation, or when the project already has azure.yaml. Example: “Prepare this application for Azure with azd and generate azure.yaml plus Bicep infrastructure.” The workflow requires creating .azure/deployment-plan.md in the workspace root first, completing and presenting the plan, and obtaining approval before execution. After preparation, update the plan status to Ready for Validation and hand off to azure-validate; do not run deployment commands directly.