terraform-patterns
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- DevOps
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: terraform-patterns
description: **UTILITY SKILL** — Reusable Azure Terraform patterns: hub-spoke, private endpoints, diagnostics…
category: devops
runtime: no special runtime
---
# terraform-patterns output preview
## PART A: Task fit
- Use case: **UTILITY SKILL** — Reusable Azure Terraform patterns: hub-spoke, private endpoints, diagnostics, AVM-TF modules. WHEN: "hub-spoke Terraform", "private endpoint module", "AVM-TF composition", "diagnostic settings", "plan interpretation". DO NOT USE FOR: Bicep code (azure-bicep-patterns), ADRs (azure-adr), diagrams (drawio). Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Quick Reference / Canonical Example — Module Composition / Rules” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “**UTILITY SKILL** — Reusable Azure Terraform patterns: hub-spoke, private endpoints, diagnostics, AVM-TF modules. WHEN: "hub-spoke Terraform", "private endpoint module", "AVM-TF composition", "diagnostic settings", "plan interpretation". DO NOT USE FOR: Bicep code (azure-bicep-patterns), ADRs (azure-adr), diagrams (drawio). Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Quick Reference / Canonical Example — Module Composition / Rules” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Quick Reference / Canonical Example — Module Composition / Rules”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: terraform-patterns
description: **UTILITY SKILL** — Reusable Azure Terraform patterns: hub-spoke, private endpoints, diagnostics…
category: devops
source: tomevault-io/skills-registry
---
# terraform-patterns
## When to use
- **UTILITY SKILL** — Reusable Azure Terraform patterns: hub-spoke, private endpoints, diagnostics, AVM-TF modules. WHEN…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Quick Reference / Canonical Example — Module Composition / Rules” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "terraform-patterns" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Quick Reference / Canonical Example — Module Composition / Rules
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Azure Terraform Patterns Skill
Composable architecture building blocks for Azure Terraform. Complements
iac-terraform-best-practices.instructions.md (style) and azure-defaults skill (naming, tags, regions).
Canonical sources — the security baseline, AVM-first mandate, naming conventions, required tags, and unique-suffix rule live in
azure-defaults/SKILL.mdandiac-policy-compliance.md. This skill restates the rules tersely below for IaC-output convenience only; in conflict, the canonical sources win.
Quick Reference
| Pattern | When to Use | Reference |
|---|---|---|
| Hub-Spoke Networking | Multi-workload environments with shared services | references/hub-spoke-pattern.md |
| Private Endpoint Wiring | Any PaaS service requiring private connectivity | references/private-endpoint-pattern.md |
| Diagnostic Settings | Every deployed resource (mandatory) | references/common-patterns.md |
| Conditional Deployment | Optional resources controlled by variables | references/common-patterns.md |
| Module Composition | Calling multiple AVM modules in root module | See inline example below |
| Managed Identity | Any service-to-service authentication | references/common-patterns.md |
| Budget & Cost Monitoring | Every deployment (mandatory) | references/budget-pattern.md |
| Plan Interpretation | Pre-deployment validation and change analysis | references/plan-interpretation.md |
| AVM Pitfalls | Set-type diffs, provider pins, 4.x changes | references/avm-pitfalls.md |
| AVM Authoring | AVM certification requirements, compliance | references/avm-authoring-requirements.md |
| Module Refactoring | Monolith → module extraction, state migration | references/refactor-module.md |
Canonical Example — Module Composition
Wire AVM child modules by passing outputs as inputs (module.<name>.<output>); never
hardcode IDs. AVM-TF module versions in APEX-generated code MUST be exact semver
(version = "X.Y.Z") — pinned at plan time from
registry.terraform.io (newest stable in modules[0].versions[]). Range
constraints (~> X.Y, >= X.Y.Z) are NOT allowed in 04-iac-contract.json and
will be flagged by npm run validate:avm-versions. Full code sample
(resource group + key vault) and rationale in
references/module-composition.md.
Rules
- AVM-first: Use
Azure/avm-res-*registry modules over rawazurerm_*resources - AVM-TF version pins: Exact semver only (
version = "X.Y.Z") — resolve the latest stable viaregistry.terraform.io/v1/modules/Azure/avm-res-{path}/azurerm/versionsat plan time. Stale pins need apin_policy.mode = "exception"block in04-iac-contract.json. Range constraints (~>,>=) are flagged byvalidate:avm-versions. - Hub-spoke: Spokes peer to hub only; never spoke-to-spoke
- Private endpoints: Three resources per service — PE, DNS zone, VNet link
- Diagnostics: Every resource MUST have a diagnostic setting → Log Analytics
- Conditional: Use
for_each(keyed) overcount(indexed) for named resources - Identity: SystemAssigned managed identity + RBAC; avoid keys/connection strings
- Provider pin:
~> 4.0(allows 4.x patches, blocks 5.0) - Telemetry: Set
enable_telemetry = falsein restricted-network environments - Moved blocks: Use
moved {}when renaming resources to prevent destroy/recreate - Budget: 3 forecast thresholds (80%/100%/120%); amount and emails MUST be variables
Steps
Applying a Terraform pattern in a root module:
- Identify the pattern — match your need to a row in Quick Reference (hub-spoke, private endpoint, diagnostics, conditional, identity, budget, plan interpretation)
- Load the reference — read the linked
references/*.md; do not load all at once - Compose AVM modules — wire outputs as inputs (see Canonical Example); never hardcode IDs
- Pin the provider —
~> 4.0only; do not use>= 3.0or exact= 4.x.y - Add diagnostics + budget — every resource gets a diagnostic setting; every deployment gets a budget with 80%/100%/120% forecast alerts
- Plan before apply —
terraform plan -out=plan.tfplan; review for~/-/+/-operations againstreferences/plan-interpretation.md - Validate —
terraform fmt -check,terraform validate,npm run validate:terraform,npm run validate:iac-security-baseline
Gotchas
- Set-type phantom diffs —
azurerm_application_gateway,azurerm_lb,azurerm_network_security_group,azurerm_firewall,azurerm_frontdoor: adding ONE element causes ALL elements to show~changes. Mitigation:ignore_changeson set-type blocks. - Provider pin
~> 4.0is critical —>= 3.0crosses breaking versions;= 4.1.0blocks patches. MUST use~> 4.0. for_eachovercountfor named resources —countcauses drift when items are inserted/removed (Terraform reindexes). Usefor_each = toset().movedblock required for renaming — Renaming a resource ID without amoved {}block causes destroy + recreate.- azurerm 4.x renamed attributes —
allow_blob_public_access→allow_nested_items_to_be_public;enable_https_traffic_only→https_traffic_only_enabled;azurerm_app_serviceremoved → useazurerm_linux_web_app.
Reference Index
| File | Contents |
|---|---|
references/hub-spoke-pattern.md |
Full hub & spoke VNet + peering HCL |
references/private-endpoint-pattern.md |
PE + DNS zone + VNet link HCL, subresource table |
references/common-patterns.md |
Diagnostics, conditional deployment, module composition, identity |
references/budget-pattern.md |
Consumption budget, forecast alerts, anomaly detection |
references/plan-interpretation.md |
Plan commands, change symbols, red flags, summary script |
references/avm-pitfalls.md |
Set-type diffs, provider pins, tag ignore, moved blocks, 4.x |
references/tf-best-practices-examples.md |
Best-practice code examples, formatting, code review checklist |
references/bootstrap-backend-template.md |
Backend bootstrap template |
references/deploy-script-template.md |
Deployment script template |
references/project-scaffold.md |
Project scaffolding structure |
references/avm-authoring-requirements.md |
AVM certification: 37 requirements, compliance checklist |
references/refactor-module.md |
Module extraction, state migration, refactoring patterns |
references/module-composition.md |
Canonical AVM module composition example with output wiring |
Source: aivandelindt/azure-agentic-infraops — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review