Use when the user needs guidance on bicep-code-best-practices. GitHub Copilot instruction from the awesome-copilot collection.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add anubhavg-icpl/vibe --skill ghcopilot-instr-bicep-code-best-practices --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Ghcopilot Instr Bicep Code Best Practices?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/anubhavg-icpl-ghcopilot-instr-bicep-code-best-practices)More formats (shields.io, HTML) on the badges page.
---
name: ghcopilot-instr-bicep-code-best-practices
description: "Use when the user needs guidance on bicep-code-best-practices. GitHub Copilot instruction from the awesome-copilot collection."
license: CC-BY-NC-SA-4.0
metadata:
version: "1.0.0"
tags: [copilot-instruction, community, bicep-code-best-practices]
applyTo: "**/*.bicep"
source: "awesome-copilot"
---
## 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
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!