agentleFS
Microsoft AzureKnown publisherAzure/azure-verified-modules-managed-files/terraform/root/.github/skills/avm-tf-codestyle/SKILL.md

avm-tf-codestyle

Skill1 starsChanged 2 months agoMITView on GitHub

Use for AVM Terraform file layout, HCL style, variables, outputs, validation, lifecycle syntax, provider requirements, and Avm.Authoring formatting.

232 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 5 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Do not add root-level providers.tf, module.tf, or everything.tf.

    line 24
  2. Very specific:

    Do not raise required_version only because non-empty ignore_body_changes needs Terraform 1.11.

    line 49
  3. Distinctive:

    Use snake case for Terraform identifiers.

    line 53
  4. Very specific:

    Default collections to {} or [] with nullable = false.

    line 57
  5. Very specific:

    Use optional(...) for non-required object attributes and give defaults that match the documentation.

    line 58
  6. Very specific:

    Keep variable, local, resource, module, and output ordering consistent with the transforms applied by avm transform.

    line 59
  7. Distinctive:

    Prefer discrete computed outputs over whole-resource outputs.

    line 60
  8. Distinctive:

    Every AzAPI resource must:

    line 89
  9. Very specific:

    Use static lifecycle.ignore_changes for compile-time-static references.

    line 111
  10. Very specific:

    Do not hand-edit managed telemetry or provider-version content that avm sync or avm transform owns.

    line 120
  11. Distinctive:

    Keep comments rare and limited to non-obvious constraints or documented exceptions.

    line 121
  12. Distinctive:

    Use the PowerShell module rather than individual binaries:

    line 125

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

AVM Terraform Code Style

Fetch the current Terraform non-functional specifications through https://azure.github.io/Azure-Verified-Modules/llms.txt. Current module examples can lag the specification and are not authoritative.

Standard file layout

TFNFR39 applies to the root module and every submodule:

FileRequirementContents
terraform.tfMUSTThe single terraform {} block with required Terraform and provider versions.
variables.tfMUSTVariable blocks.
outputs.tfMUSTOutput blocks.
main.tfMUSTPrimary resource, data, and module blocks.
locals.tfRequired when locals existLocal values only.

Large modules may use main.<topic>.tf, variables.<topic>.tf, outputs.<topic>.tf, and locals.<topic>.tf. Topic names are snake case and each file contains only the block kind indicated by its prefix.

Do not add root-level providers.tf, module.tf, or everything.tf. Reusable AVM modules declare provider requirements but never provider configurations.

Each module and submodule also includes _header.md and _footer.md; README.md is generated.

Provider requirements

Every new module repository that deploys Azure resources MUST use AzAPI for every control-plane and supported direct Azure operation. Do not declare or configure hashicorp/azurerm, and do not create any azurerm_* resource or data source for convenience or ordinary supporting infrastructure in implementation, submodules, examples, E2E configurations, Terraform tests, fixtures, setup or teardown Terraform, migration examples, documentation examples, or generated snippets.

TFNFR25 requires a minimum and maximum Terraform CLI constraint, while TFFR3 requires the AzAPI provider range. Use the governance-managed baseline; a compliant current shape is:

terraform {
  required_version = ">= 1.9, < 2.0"

  required_providers {
    azapi = {
      source  = "Azure/azapi"
      version = "~> 2.12"
    }
  }
}

Apply this Azure/azapi requirement to every standalone Terraform root that directly creates, reads, or acts on Azure resources. Supporting resources outside the module under test use AzAPI. Each permitted azurerm_* resource or data-source block must independently implement one specific unsupported data-plane/non-ARM operation, document the exact block and why AzAPI cannot implement it with an upstream AzAPI issue or pull request, and be replaced when support ships. One valid block does not authorize another.

Do not raise required_version only because non-empty ignore_body_changes needs Terraform 1.11. Emit null when that interface is unused so earlier supported Terraform versions remain compatible.

Naming and declarations

  • Use snake case for Terraform identifiers.
  • Name the primary AzAPI resource this; name satellite resources after their purpose.
  • Give every variable and output a precise type and description.
  • Mark secret variables and outputs sensitive and follow the current ephemeral-value requirements.
  • Default collections to {} or [] with nullable = false.
  • Use optional(...) for non-required object attributes and give defaults that match the documentation.
  • Keep variable, local, resource, module, and output ordering consistent with the transforms applied by avm transform.
  • Prefer discrete computed outputs over whole-resource outputs.

Example:

variable "private_endpoints" {
  type = map(object({
    name               = optional(string)
    subnet_resource_id = string
  }))
  default  = {}
  nullable = false

  validation {
    condition = alltrue([
      for endpoint in values(var.private_endpoints) :
      can(provider::azapi::parse_resource_id("Microsoft.Network/virtualNetworks/subnets", endpoint.subnet_resource_id))
    ])
    error_message = "Each private endpoint subnet must be a valid subnet resource ID."
  }

  description = "A map of private endpoints to create."
}

TFNFR38 requires provider::azapi::parse_resource_id with a literal expected resource type for ARM resource IDs. Short-circuit optional values and iterate collections or nested attributes. Do not use regex, startswith, length, or split as substitutes, except for the prescribed generic check on an extension-resource module's polymorphic parent_id under TFRMFR1.

AzAPI block requirements

Every AzAPI resource must:

  • source type from the deterministic field in var.resource_types;
  • declare response_export_values;
  • omit replace_triggers_refs when no replacement paths exist; otherwise declare a non-empty static list of unique, valid JMESPath body paths;
  • assign retry = var.retry;
  • emit timeouts through a dynamic block; and
  • assign the per-resource ignore_body_changes list, collapsing empty to null.
  • set tags = var.tags exactly on resource types supported by the current AVM TFLint capability snapshot and omit tags on unsupported types.

See avm-tf-azapi for the complete pattern.

Lifecycle syntax

Terraform lifecycle references are expressions, not strings:

lifecycle {
  ignore_changes = [tags]
}

Use static lifecycle.ignore_changes for compile-time-static references. Use the consumer-configurable AzAPI ignore_body_changes interface when body paths are dynamic. Body paths are strings because they are passed to the provider:

ignore_body_changes = length(var.ignore_body_changes.example_widgets) > 0 ? var.ignore_body_changes.example_widgets : null

Generated and managed files

  • Edit _header.md or _footer.md, not README.md.
  • Do not hand-edit managed telemetry or provider-version content that avm sync or avm transform owns.
  • Keep comments rare and limited to non-obvious constraints or documented exceptions.

Formatting and validation

Use the PowerShell module rather than individual binaries:

avm transform
avm format
avm docs
avm pre-commit

Review and commit all resulting changes, then run:

avm pr-check

avm pr-check requires a clean Git worktree. Do not use Make, the old repository launcher, a container, Porch, or a separately installed formatter to approximate these checks.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.