terragrunt-generator_skill

This skill generates production-ready Terragrunt configurations following current best practices, enabling consistent multi-environment roots and modular child
  • HCL

83

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill akin-ozer/cc-devops-skills --skill terragrunt-generator

  • SKILL.md26.2 KB

Overview

This skill is a comprehensive toolkit for generating production-ready Terragrunt HCL configurations that follow current Terragrunt 2025 best practices, naming conventions, and security standards. It produces validated root, child, module, stack, feature-flag, exclude, errors, and engine configurations and enforces generation workflows to avoid common mistakes. Use it to bootstrap new Terragrunt projects or to add multi-environment structure consistently and safely.

How this skill works

The generator inspects your requested architecture pattern (Pattern A/B/C), required templates, and target environments, then emits HCL files from templates while running inline validation checks. Before any files are written it outputs a mandatory pre-generation checklist with concrete selections and verified paths. Generated files replace template placeholders (bucket, region, terraform/provider versions, project and environment names), include remote-state and provider blocks, and add 2025 constructs such as stacks, feature flags, exclude and errors blocks when requested.

When to use it

  • Bootstrapping a new Terragrunt project with best-practice structure
  • Creating multi-environment directories (dev/staging/prod) or single-environment roots
  • Generating root.hcl, child terragrunt.hcl, standalone module configs, or stacks
  • Adding feature flags, exclude, or errors blocks to improve runtime safety
  • Switching to OpenTofu engine or adding custom provider requirements

Best practices

  • Select and document the architecture pattern (A/B/C) before generating any files
  • Prefer environment-agnostic root.hcl for multi-environment projects (Pattern A)
  • Use path_relative_to_include() for state keys and get_env() for runtime values
  • Keep feature flag defaults static; set environment-specific defaults in env.hcl
  • Protect critical resources with exclude actions and prevent_destroy where needed

Example use cases

  • Generate a Pattern A project: root.hcl + dev/prod env.hcl + vpc/rds child modules
  • Create a single-environment Pattern B root that derives environment from path or TG_ENVIRONMENT
  • Build a terragrunt.stack.hcl catalog and generate units for a multi-unit blueprint
  • Add OpenTofu engine config and required_providers block for non-Terraform providers
  • Produce standalone module configs for reusable module testing and CI

FAQ

The generator outputs a completed Architecture Pattern Selection checklist confirming pattern choice, root.hcl scope, env.hcl locations, child access method, and path verifications.

Can feature flags use dynamic locals as defaults?

No. Feature flag defaults must be static values (boolean, string, number). Use environment-specific env.hcl to provide different static defaults per environment.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
terragrunt-generator skill by akin-ozer/cc-devops-skills | VeilStrat