Agent skill
format-bicep
Format Bicep code for readability and consistency.
Install this agent skill to your Project
npx add-skill https://github.com/johnlokerse/azure-bicep-github-copilot/tree/main/.github/skills/format-bicep
SKILL.md
Format Bicep
This skill reformats Bicep code to enhance readability and maintainability by applying consistent styling, indentation, and organization.
Guidelines
To format a Bicep file, follow these guidelines:
Bicep structure
To avoid chaos keep a strict structure for Bicep files. The recommended structure is as follows:
////////////
// Imports
////////////
////////////
// Metadata (optional)
////////////
////////////
// TargetScope (optional)
////////////
////////////
// Parameters
////////////
////////////
// Variables
////////////
////////////
// Existing resource references
////////////
////////////
// Resources / Modules
////////////
////////////
// Outputs
////////////
////////////
// User-Defined Types Types
////////////
////////////
// Functions
////////////
Do not add blank lines between section comment headers and the first definition in that section.
Correct:
////////////
// Parameters
////////////
@description('The supported Azure location')
param location string
Wrong:
////////////
// Parameters
////////////
@description('The supported Azure location')
param location string
Property order on resource and modules
Resource definitions should follow a consistent property order:
resource <name> '<type>@<apiVersion>' = {
name: '<name>'
location: '<location>'
tags: '<tags>'
<property>: '<otherProperties>' // other resource-specific properties in alphabetical order
dependsOn: [
// dependencies
] // optional, prefer implicit dependencies
properties: {
// resource-specific properties
}
}
Module defitinitions should follow a consistent property order. If the module has the name property, it should be removed since the Azure Resource Manager handles the deployment name.
module <name> '<path>' = {
scope: '<scope>' // optional
identity: {
// identity properties
} // optional
dependsOn: [
// dependencies
] // optional, prefer implicit dependencies
params: {
// module parameters
}
}
Execution steps
When formatting a Bicep file, perform these steps in order:
-
Analyze the current structure
- Identify existing sections (parameters, variables, resources, etc.)
- Note any missing required sections
-
Reorganize sections according to the standard structure
- Move items to their correct section
- Add section comment headers if missing
- Ensure to return feedback about any significant structural changes made. DO NOT REMOVE any code, only reorganize it.
-
Apply property ordering
- Reorder resource/module properties as specified
- Ensure decorators are in the correct order
-
Run bicep format
- Run command:
bicep format <.bicep file>
- Run command:
-
Remove commented code
- Delete any commented-out code blocks
- Retain comments that provide context or explanations
-
Validate the result
- Ensure no syntax errors were introduced
- Verify the file compiles successfully
Use the following command to compile and validate the Bicep file:
bicep build <.bicep file> --stdout --no-restore
Examples
Before Formatting
param location string='eastus'
var storageAccountName='mystorageaccount'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01'={
name:storageAccountName
location:location
properties:{
accessTier:'Hot'
}
sku:{name:'Standard_LRS'}
}
After Formatting
/*
Parameters
*/
@sys.description('The Azure region for resource deployment')
param location string = 'eastus'
/*
Variables
*/
var storageAccountName = 'mystorageaccount'
/*
Resources
*/
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
properties: {
accessTier: 'Hot'
}
}
Didn't find tool you were looking for?