skills/azure-deployment-preflight/SKILL.md
Performs comprehensive preflight validation of Bicep deployments to Azure, including template syntax validation, what-if analysis, and permission checks. Use this skill before any deployment to Azure to preview changes, identify potential issues, and ensure the deployment will succeed. Activate when users mention deploying to Azure, validating Bicep files, checking deployment permissions, previewing infrastructure changes, running what-if, or preparing for azd provision.
npx skillsauth add github/awesome-copilot azure-deployment-preflightInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
4 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill validates Bicep deployments before execution, supporting both Azure CLI (az) and Azure Developer CLI (azd) workflows.
azd up, azd provision, or az deployment commandsFollow these steps in order. Continue to the next step even if a previous step fails—capture all issues in the final report.
Determine the deployment workflow by checking for project indicators:
Check for azd project: Look for azure.yaml in the project root
Locate Bicep files: Find all .bicep files to validate
infra/ directory first, then project rootinfra/, deploy/, project root)Auto-detect parameter files: For each Bicep file, look for matching parameter files:
<filename>.bicepparam (Bicep parameters - preferred)<filename>.parameters.json (JSON parameters)parameters.json or parameters/<env>.json in same directoryRun Bicep CLI to check template syntax before attempting deployment validation:
bicep build <bicep-file> --stdout
What to capture:
If Bicep CLI is not installed:
Choose the appropriate validation based on project type detected in Step 1.
Use azd provision --preview to validate the deployment:
azd provision --preview
If an environment is specified or multiple environments exist:
azd provision --preview --environment <env-name>
Determine the deployment scope from the Bicep file's targetScope declaration:
| Target Scope | Command |
|--------------|---------|
| resourceGroup (default) | az deployment group what-if |
| subscription | az deployment sub what-if |
| managementGroup | az deployment mg what-if |
| tenant | az deployment tenant what-if |
Run with Provider validation level first:
# Resource Group scope (most common)
az deployment group what-if \
--resource-group <rg-name> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
# Subscription scope
az deployment sub what-if \
--location <location> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
# Management Group scope
az deployment mg what-if \
--location <location> \
--management-group-id <mg-id> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
# Tenant scope
az deployment tenant what-if \
--location <location> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
Fallback Strategy:
If --validation-level Provider fails with permission errors (RBAC), retry with ProviderNoRbac:
az deployment group what-if \
--resource-group <rg-name> \
--template-file <bicep-file> \
--validation-level ProviderNoRbac
Note the fallback in the report—the user may lack full deployment permissions.
Parse the what-if output to categorize resource changes:
| Change Type | Symbol | Meaning |
|-------------|--------|---------|
| Create | + | New resource will be created |
| Delete | - | Resource will be deleted |
| Modify | ~ | Resource properties will change |
| NoChange | = | Resource unchanged |
| Ignore | * | Resource not analyzed (limits reached) |
| Deploy | ! | Resource will be deployed (changes unknown) |
For modified resources, capture the specific property changes.
Create a Markdown report file in the project root named:
preflight-report.mdUse the template structure from references/REPORT-TEMPLATE.md.
Report sections:
Before running validation, gather:
| Information | Required For | How to Obtain |
|-------------|--------------|---------------|
| Resource Group | az deployment group | Ask user or check existing .azure/ config |
| Subscription | All deployments | az account show or ask user |
| Location | Sub/MG/Tenant scope | Ask user or use default from config |
| Environment | azd projects | azd env list or ask user |
If required information is missing, prompt the user before proceeding.
See references/ERROR-HANDLING.md for detailed error handling guidance.
Key principle: Continue validation even when errors occur. Capture all issues in the final report.
| Error Type | Action |
|------------|--------|
| Not logged in | Note in report, suggest az login or azd auth login |
| Permission denied | Fall back to ProviderNoRbac, note in report |
| Bicep syntax error | Include all errors, continue to other files |
| Tool not installed | Note in report, skip that validation step |
| Resource group not found | Note in report, suggest creating it |
This skill uses the following tools:
az) - Version 2.76.0+ recommended for --validation-levelazd) - For projects with azure.yamlbicep) - For syntax validationCheck tool availability before starting:
az --version
azd version
bicep --version
azure.yaml → azd projectinfra/main.bicep and infra/main.bicepparambicep build infra/main.bicep --stdoutazd provision --previewpreflight-report.md in project roottools
End-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI. Covers all four build backends (setuptools+setuptools_scm, hatchling, flit, poetry), PEP 440 versioning, semantic versioning, dynamic git-tag versioning, OOP/SOLID design, type hints (PEP 484/526/544/561), Trusted Publishing (OIDC), and the full PyPA packaging flow. Use for: creating Python packages, pip-installable SDKs, CLI tools, framework plugins, pyproject.toml setup, py.typed, setuptools_scm, semver, mypy, pre-commit, GitHub Actions CI/CD, or PyPI publishing.
tools
Audit MCP (Model Context Protocol) server configurations for security issues. Use this skill when: - Reviewing .mcp.json files for security risks - Checking MCP server args for hardcoded secrets or shell injection patterns - Validating that MCP servers use pinned versions (not @latest) - Detecting unpinned dependencies in MCP server configurations - Auditing which MCP servers a project registers and whether they're on an approved list - Checking for environment variable usage vs. hardcoded credentials in MCP configs - Any request like "is my MCP config secure?", "audit my MCP servers", or "check .mcp.json" keywords: [mcp, security, audit, secrets, shell-injection, supply-chain, governance]
tools
Enable code intelligence (go-to-definition, find-references, hover, type info) for any programming language by installing and configuring an LSP server for Copilot CLI. Detects the OS, installs the right server, and generates the JSON configuration (user-level or repo-level). Use when you need deeper code understanding and no LSP server is configured, or when the user asks to set up, install, or configure an LSP server.
development
Use this skill whenever the user wants to build scroll animations, scroll effects, parallax, scroll-triggered reveals, pinned sections, horizontal scroll, text animations, or any motion tied to scroll position — in vanilla JS, React, or Next.js. Covers GSAP ScrollTrigger (pinning, scrubbing, snapping, timelines, horizontal scroll, ScrollSmoother, matchMedia) and Framer Motion / Motion v12 (useScroll, useTransform, useSpring, whileInView, variants). Use this skill even if the user just says "animate on scroll", "fade in as I scroll", "make it scroll like Apple", "parallax effect", "sticky section", "scroll progress bar", or "entrance animation". Also triggers for Copilot prompt patterns for GSAP or Framer Motion code generation. Pairs with the premium-frontend-ui skill for creative philosophy and design-level polish.