Claude-skill-registry bicep

Expert assistance for Azure Bicep infrastructure-as-code. Provides best practices for authoring Bicep templates, Azure resource type discovery with API versions, resource schema retrieval, and Azure Verified Modules (AVM) guidance. Use when writing Bicep files, deploying Azure resources, looking up resource types/schemas, or working with AVM modules.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/bicep" ~/.claude/skills/majiayu000-claude-skill-registry-bicep-b08a47 && rm -rf "$T"
manifest: skills/data/bicep/SKILL.md
source content

Bicep Expert Assistant

Expert guidance for Azure Bicep infrastructure-as-code development, including best practices, resource type discovery, schema retrieval, and Azure Verified Modules.

Core Capabilities

This skill provides four main functions equivalent to the Bicep MCP Server:

  1. Best Practices - Comprehensive Bicep authoring guidelines
  2. Resource Type Discovery - List Azure resource types with API versions
  3. Schema Retrieval - Get detailed schemas for resource types
  4. AVM Metadata - Azure Verified Modules information

Instructions

When User Asks About Bicep Best Practices

Provide guidance from the comprehensive best practices below. Focus on the specific area they're asking about (parameters, variables, resources, modules, naming, security, etc.).

When User Needs Resource Types for a Provider

Run the helper script to list resource types:

# PowerShell
./scripts/get-resource-types.ps1 -Provider "Microsoft.Storage"

# Bash
./scripts/get-resource-types.sh "Microsoft.Storage"

Or use Azure CLI directly:

az provider show --namespace Microsoft.Storage --query "resourceTypes[].{Type:resourceType,ApiVersions:apiVersions[0]}" -o table

When User Needs a Resource Schema

Use Bicep CLI to get the schema:

bicep build-params --stdout <<< "param resourceType string = 'Microsoft.Storage/storageAccounts@2023-05-01'"

Or reference the helper script in

scripts/get-resource-schema.ps1

When User Asks About Azure Verified Modules

Provide AVM guidance and help them find appropriate modules from the Bicep Public Registry.


Bicep Best Practices Reference

Parameters

  1. Use descriptive names: Parameters should have clear, meaningful names that indicate their purpose

    // Good
    param storageAccountName string
    param enableHttpsTrafficOnly bool = true
    
    // Avoid
    param san string
    param flag bool
    
  2. Provide descriptions: Always add

    @description()
    decorator

    @description('The name of the storage account. Must be globally unique.')
    param storageAccountName string
    
  3. Set safe defaults: Default values should be secure and cost-effective

    @description('The SKU for the storage account')
    @allowed(['Standard_LRS', 'Standard_GRS', 'Standard_ZRS', 'Premium_LRS'])
    param storageAccountSku string = 'Standard_LRS'
    
  4. Use constraints wisely: Apply

    @minLength()
    ,
    @maxLength()
    ,
    @minValue()
    ,
    @maxValue()

    @minLength(3)
    @maxLength(24)
    param storageAccountName string
    
  5. Use

    @allowed
    sparingly: Overly restrictive lists block valid deployments as Azure adds new SKUs

  6. Secure sensitive parameters: Use

    @secure()
    for secrets

    @secure()
    param adminPassword string
    

Variables

  1. Use for computed values: Variables simplify complex expressions

    var storageAccountName = '${prefix}${uniqueString(resourceGroup().id)}'
    
  2. Use for repeated values: Define once, use multiple times

    var commonTags = {
      environment: environment
      project: projectName
      deployedBy: 'Bicep'
    }
    
  3. Typed variables (Bicep 0.26+): Add types for clarity

    var instanceCount int = environment == 'prod' ? 5 : 2
    

Resources

  1. Use symbolic names without 'name' suffix:

    // Good
    resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
    
    // Avoid
    resource storageAccountName 'Microsoft.Storage/storageAccounts@2023-05-01' = {
    
  2. Use latest stable API versions: Check for the most recent stable API version

  3. Leverage implicit dependencies: Bicep automatically handles dependencies when you reference resources

    resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
      name: storageAccountName
      // ...
    }
    
    resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-05-01' = {
      parent: storageAccount  // Implicit dependency
      name: 'default'
    }
    
  4. Use

    existing
    keyword for references:

    resource existingVnet 'Microsoft.Network/virtualNetworks@2023-09-01' existing = {
      name: vnetName
    }
    

Child Resources

  1. Use nested declaration (preferred):

    resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
      name: storageAccountName
      // ...
    
      resource blobService 'blobServices' = {
        name: 'default'
      }
    }
    
  2. Or use parent property:

    resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-05-01' = {
      parent: storageAccount
      name: 'default'
    }
    

Modules

  1. Use modules for reusability: Break large templates into focused modules

    module storageModule 'modules/storage.bicep' = {
      name: 'storageDeployment'
      params: {
        storageAccountName: storageAccountName
        location: location
      }
    }
    
  2. Use Azure Verified Modules: Leverage pre-built, tested modules from the Bicep Registry

    module storage 'br/public:avm/res/storage/storage-account:0.9.0' = {
      name: 'storageDeployment'
      params: {
        name: storageAccountName
        location: location
      }
    }
    
  3. Version your modules: Always pin to specific versions

Naming Conventions

  1. Use camelCase for parameters, variables, and symbolic names
  2. Use
    uniqueString()
    for unique names
    :
    var storageAccountName = 'st${uniqueString(resourceGroup().id)}'
    
  3. Add prefixes for context: Include environment, project, or region prefixes
  4. Follow Azure naming constraints: Check character limits and allowed characters

Outputs

  1. Expose essential values: Output what consumers need

    output storageAccountId string = storageAccount.id
    output primaryEndpoints object = storageAccount.properties.primaryEndpoints
    
  2. Never output secrets: Use Key Vault references instead

    // WRONG - Never do this
    output connectionString string = storageAccount.listKeys().keys[0].value
    

Security Best Practices

  1. Use managed identities instead of credentials where possible
  2. Enable HTTPS/TLS for all services
  3. Use private endpoints for sensitive resources
  4. Apply least privilege with RBAC assignments
  5. Enable diagnostic logging and monitoring
  6. Use Key Vault for secrets management
  7. Enable encryption at rest and in transit

Code Organization

  1. File structure:

    project/
    ├── main.bicep           # Entry point
    ├── main.bicepparam      # Parameters file
    ├── modules/
    │   ├── networking.bicep
    │   ├── storage.bicep
    │   └── compute.bicep
    └── tests/
        └── main.tests.bicep
    
  2. Order of elements in files:

    • Target scope (if not resourceGroup)
    • Parameters
    • Variables
    • Resources
    • Modules
    • Outputs
  3. Comments: Use

    //
    for single-line,
    /* */
    for multi-line


Azure Verified Modules (AVM)

What is AVM?

Azure Verified Modules are pre-built, tested Bicep modules maintained by Microsoft that follow best practices and the Well-Architected Framework.

Using AVM Modules

// Reference from Bicep Public Registry
module storage 'br/public:avm/res/storage/storage-account:0.9.0' = {
  name: 'storageDeployment'
  params: {
    name: 'mystorageaccount'
    location: location
  }
}

Finding AVM Modules

  1. Browse: https://azure.github.io/Azure-Verified-Modules/indexes/bicep/
  2. GitHub: https://github.com/Azure/bicep-registry-modules
  3. Registry:
    mcr.microsoft.com
    for container images

Module Types

  • Resource Modules (
    avm/res/
    )
    : Single Azure resource with all configurations
  • Pattern Modules (
    avm/ptn/
    )
    : Multi-resource patterns for common scenarios
  • Utility Modules (
    avm/utl/
    )
    : Helper types and functions

Common Resource Type Examples

Storage Account

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTls  }
}

Virtual Network

resource vnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'default'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }
}

Key Vault

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: keyVaultName
  location: location
  properties: {
    tenantId: subscription().tenantId
    sku: {
      family: 'A'
      name: 'standard'
    }
    enableRbacAuthorization: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
  }
}

When to Use This Skill

  • Writing or reviewing Bicep templates
  • Looking up Azure resource types and API versions
  • Finding the correct schema for a resource type
  • Using Azure Verified Modules
  • Applying Bicep best practices
  • Deploying Azure infrastructure with IaC

Keywords

bicep, azure, arm, infrastructure as code, iac, resource manager, deployment, template, module, avm, azure verified modules, resource type, schema, api version, storage account, virtual network, key vault, best practices