bicep-code-best-practices — GitHub Copilot rule: purpose and setup
This rule guides GitHub Copilot when editing Bicep files, covering naming, parameters, resource references, and outputs. Use it to keep infrastructure code consistent with the stated conventions.
.github/instructions/bicep-code-best-practices.instructions.mdWhat bicep-code-best-practices does
The rule applies to files matching **/*.bicep. It asks for parameters at the top of each file, descriptive @description decorators, and lower camel case names. It recommends stable resource API versions and moving complex expressions into variables rather than embedding them in resource properties.
For resource references, it favors symbolic names over reference() and resourceId(), and symbolic dependencies over explicit dependsOn. Resource names can use uniqueString() with a prefix; child resources should use parent or nesting. Secrets and keys must stay out of outputs. Default values should be safe for test environments, including low-cost pricing tiers, so review those defaults before deploying beyond a test setup.
What it helps with
- Keep Bicep parameter and resource names consistent
- Document parameters and constrain naming lengths
- Replace explicit dependencies with symbolic references
- Build resource names with
uniqueString()and a prefix - Keep secrets and keys out of outputs
Example prompts for the agent
- Create a Bicep template using the naming and parameter conventions in this rule.
- Review this
.bicepfile and replace explicit resource dependencies with symbolic references. - Add documented parameters with safe defaults for a test environment.
How to install bicep-code-best-practices
Manually: put the files in place
.github/instructions/bicep-code-best-practices.instructions.mdThe applyTo field sets which files it applies to
Manually: put the files in place
.claude/rules/bicep-code-best-practices.mdThe paths frontmatter field limits the files: move applyTo from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.cursor/rules/bicep-code-best-practices.mdcFrontmatter: description, globs, alwaysApply. Move applyTo from the source into globs, or the rule will not attach on its own
Manually: put the files in place
.devin/rules/bicep-code-best-practices.mdManually: put the files in place
.clinerules/bicep-code-best-practices.mdStep by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use
Questions about bicep-code-best-practices
How do I install bicep-code-best-practices in GitHub Copilot?
Add the rule file to your project at .github/instructions/bicep-code-best-practices.instructions.md.
What does bicep-code-best-practices do?
It guides Bicep authoring, including parameter declarations, resource naming, and resource references. It also says not to put secrets or keys in outputs.
Which files does the rule apply to?
It applies to files matching **/*.bicep.
Source text
bicep-code-best-practices.instructions.md · MIT
--- description: 'Infrastructure as Code with Bicep' applyTo: '**/*.bicep' --- ## Naming Conventions - When writing Bicep code, use lowerCamelCase for all names (variables, parameters, resources) - Use resource type descriptive symbolic names (e.g., 'storageAccount' not 'storageAccountName') - Avoid using 'name' in a symbolic name as it represents the resource, not the resource's name - Avoid distinguishing variables and parameters by the use of suffixes ## Structure and Declaration - Always declare parameters at the top of files with @description decorators - Use latest stable API versions for all resources - Use descriptive @description decorators for all parameters - Specify minimum and maximum character length for naming parameters ## Parameters - Set default values that are safe for test environments (use low-cost pricing tiers) - Use @allowed decorator sparingly to avoid blocking valid deployments - Use parameters for settings that change between deployments ## Variables - Variables automatically infer type from the resolved value - Use variables to contain complex expressions instead of embedding them directly in resource properties ## Resource References - Use symbolic names for resource references instead of reference() or resourceId() functions - Create resource dependencies through symbolic names (resourceA.id) not explicit dependsOn - For accessing properties from other resources, use the 'existing' keyword instead of passing values through outputs ## Resource Names - Use template expressions with uniqueString() to create meaningful and unique resource names - Add prefixes to uniqueString() results since some resources don't allow names starting with numbers ## Child Resources - Avoid excessive nesting of child resources - Use parent property or nesting instead of constructing resource names for child resources ## Security - Never include secrets or keys in outputs - Use resource properties directly in outputs (e.g., storageAccount.properties.primaryEndpoints) ## Documentation - Include helpful // comments within your Bicep files to improve readability
© github · MIT · github/awesome-copilot
