What problem does it solve? Bicep templates often accumulate redundant parameters, scattered environment configuration, broken tag unions, and role-assignment names that fail with BCP120 because they depend on deployment-time module outputs. This Skill applies a consistent set of Azure Bicep practices when authoring or reviewing modules so interfaces stay small, resource references stay derivable, and every change is proven with compiler and what-if evidence. ## Core Features & Use Cases - Parameter and configuration hygiene: Minimizes parameter surfaces, centralizes shared environment facts in one typed configuration object, and derives stable names instead of threading values through module layers. - Resource reference correctness: Derives ARM resource IDs with existing symbolic resources or correctly scoped resourceId(), preserves resource-specific tags with union(), and keeps guid() naming inputs compile-time resolvable to avoid BCP120. - Validation gates: Treats the Bicep linter, az bicep build, and scoped deployment what-if previews as required review evidence, including zero unexplained drift for refactors. - Use Case: A reviewer finds a role assignment named with guid(module.outputs.principalId, ...) triggering BCP120; the Skill guides moving the naming expression to a boundary where principalId is a compile-time parameter. ## Quick Start Review my Bicep module for redundant parameters, tag handling, and role-assignment naming, then tell me what build and what-if validation I still need before merging.
