Add Azure Verified Modules with Bicep language specific copilot instructions

[PlagueHO]

Pull Request Checklist

• I have read and followed the CONTRIBUTING.md guidelines.
• My contribution adds a new instruction, prompt, or chat mode file in the correct directory.
• The file follows the required naming convention.
• The content is clearly structured and follows the example format.
• I have tested my instructions, prompt, or chat mode with GitHub Copilot.
• I have run npm start and verified that README.md is up to date.

---

Description

• Introduced language specific guidelines for developing Bicep IaC with Azure Verified Modules (AVM).

---

Type of Contribution

• New instruction file.
• New prompt file.
• New chat mode file.
• New collection file.
• Update to existing instruction, prompt, chat mode, or collection.
• Other (please specify):

---

Additional Notes

---

By submitting this pull request, I confirm that my contribution abides by the Code of Conduct and will be licensed under the MIT License.

[Copilot]

Pull request overview

This pull request introduces a comprehensive instruction file for Azure Verified Modules (AVM) with Bicep language-specific guidance. The PR adds language-specific conventions and best practices to help developers use AVM modules effectively when working with Bicep Infrastructure as Code.

Key Changes:

• Added detailed Azure Verified Modules instruction file with module discovery, usage patterns, naming conventions, and validation requirements
• Updated the README to include the new instruction file in the alphabetically-sorted instruction list
• Provided comprehensive guidance on Bicep best practices specific to AVM module usage

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
instructions/azure-verified-modules-bicep.instructions.md	New instruction file providing comprehensive guidance for using Azure Verified Modules with Bicep, including module discovery, naming conventions, version management, best practices, validation requirements, and troubleshooting
docs/README.instructions.md	Added entry for the new Azure Verified Modules Bicep instruction file with installation badges, properly positioned alphabetically between Azure Terraform and Azure Verified Modules Terraform entries

---

Review Summary:

The PR is well-structured and provides valuable guidance for Bicep developers working with Azure Verified Modules. The instruction file follows the repository's conventions for front matter format, file naming, and content structure.

I've identified a few moderate documentation issues related to decorator naming that should be addressed:

• The file uses @sys.description() in multiple places, but Bicep's standard decorator is @description() without the sys prefix
• Some minor clarity improvements could be made to naming convention examples

The README update is correctly formatted and properly positioned alphabetically with other Azure-related instructions.

[Copilot]

Inconsistent decorator naming: This line uses @sys.description(), but in Bicep, the standard decorator is @description() without the sys prefix. The @sys. namespace is for system functions, not for the built-in description decorator. Update to use @description() for accuracy.

[Copilot]

Inconsistent decorator naming: This line also uses @sys.description(). Apply the same correction as above - use @description() instead of @sys.description().

Suggested change

	- [ ] `@sys.description()` on all parameters
	- [ ] `@description()` on all parameters

[Copilot]

Inconsistent terminology: The comment mentions "resource type descriptive names" but the example shows storageAccount which is a generic resource name, not the actual resource type. Consider clarifying this to say "Use resource type-based descriptive names" or provide an example that better illustrates the point (e.g., comparing sa vs storageAccount).

Suggested change

	- Use resource type descriptive names (e.g., `storageAccount` not `storageAccountName`)
	- Use resource type-based descriptive names (e.g., `storageAccount` not `sa`)

[Copilot]

The parenthetical example could be clearer. The phrase "not storageAccountName" suggests that the symbolic name should not include "name" as a suffix, but the comparison is between storageAccount and storageAccountName. Consider revising to explicitly state the guideline, such as: "Use resource type descriptive names (e.g., storageAccount or virtualNetwork, not storageAccountName or vnetName)" to make the anti-pattern more obvious.

Suggested change

	- Use resource type descriptive names (e.g., `storageAccount` not `storageAccountName`)
	- Avoid 'name' suffix in symbolic names as they represent the resource, not the resource's name
	- Use resource type descriptive names (e.g., `storageAccount` or `virtualNetwork`, not `storageAccountName` or `vnetName`)
	- Avoid using the 'name' suffix in symbolic names, as symbolic names represent the resource itself, not the resource's name property

[Copilot]

Inconsistent decorator naming: Line 94 uses @sys.description() but line 135 uses the same decorator. In Bicep, the standard decorator is @description(), not @sys.description(). The @sys. namespace is used for system functions, but description is a built-in decorator that doesn't require the sys prefix. Consider updating all references to use @description() for accuracy.

Suggested change

	- ✅ **Declare** parameters at top of file with `@sys.description()` decorators
	- ✅ **Declare** parameters at top of file with `@description()` decorators