azure-verified-modules

name	azure-verified-modules
description	Recommend and reference Azure Verified Modules (AVMs) for common Azure resource patterns. Use when a user asks whether to reimplement or customize core resources (Key Vault, Storage, Log Analytics) or when weighing trade-offs between reuse vs custom code; keywords: azure verified modules, AVM, modules, reuse, keyvault, storage, loganalytics, compliance, region

Azure Verified Modules (AVM) Skill

Summary: Enforce AVM-First policy. Azure Verified Modules are the mandatory default for all common infrastructure patterns in this repository.

Decision Rules:

1. Mandatory Use: You MUST use an AVM if a pattern exists in the AVM Index.
2. Rejection Criteria: A custom module is ONLY permitted if:
   • No AVM equivalent exists.
   • The AVM version is currently broken (documented bug).
   • Enterprise-specific sovereignty or security overrides cannot be achieved via AVM parameters.
3. Justification: If rejection criteria are met, the agent MUST write a "Justification for Custom Module" in the resulting code's README.

Usage:

• Reference AVMs using the br/avm or br/public aliases defined in bicepconfig.json.
• Pin to specific versions (e.g., 0.5.1). NEVER use latest.

Trade-offs (short):

• AVMs: upstream maintenance, security patches, standard conventions, faster time-to-deploy
• Custom: full control, possible feature coverage gaps, higher ongoing maintenance cost

NEVER / Anti-Patterns (specific + why):

• NEVER fork an AVM into your repo without an upstream tracking link and a documented update process. Forking without tracking prevents receiving important security and bug fixes.