event4u-app/agent-config

terragrunt

Use when working with Terragrunt — DRY multi-env configs, module dependencies, remote state orchestration — even when the user just says 'deploy this to staging and prod' without naming Terragrunt.

95Collecting
See how to use itView GitHub source
npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/terragrunt"

Quick start

Start using it in three steps

Install it or open the source, trigger it with a clear task, then follow the source workflow.

1

Install the Skill

npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/terragrunt"
2

Describe the task

Use terragrunt to help me with: [describe your task]. Before you begin, tell me what input you need, the steps you will follow, and the expected output.

3

Follow the workflow

No structured workflow was detected; follow the original SKILL.md below.

Continue to the workflow

Direct answers

Answers to review before you install

What is terragrunt?

Use when working with Terragrunt — DRY multi-env configs, module dependencies, remote state orchestration — even when the user just says 'deploy this to staging and prod' without naming Terragrunt.

Who should use terragrunt?

It is relevant to workflows involving Deployment, Engineering, Operations.

How do you install terragrunt?

SkillSignal detected this source-specific command: npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/terragrunt". Inspect the repository and command before running it.

Which Agent platforms does it support?

The upstream source does not declare a dedicated Agent platform.

What permissions or risks should you review?

No obvious permission action was detected by the static rules. This is not proof that the Skill is safe.

What are the current evidence limits?

This page combines upstream documentation with deterministic repository, quality, and static-risk signals. It is not described as a manual test or security review.

SkillSignal brief

Decide whether it fits your work first

Use when working with Terragrunt — DRY multi-env configs, module dependencies, remote state orchestration — even when the user just says 'deploy this to staging and prod' without naming Terragrunt.

Useful in these contexts

Not yet included in a workflow collection

Core capabilities

DeploymentEngineeringOperations

Distilled from the source

Understand this Skill in one minute

About 2 min · 12 sections

When it is worth using

  1. Use this skill when working with Terragrunt configurations (.hcl files), managing environment-specific settings, or orchestrating multi-module deployments.

Examples and typical usage

  1. Terragrunt HCL files with DRY environment configuration

  2. Dependency graph and remote state references

Repository stars
7
Repository forks
1
Quality
95/100
Source repository last pushed

Quality breakdown

Based on traceable docs and repository signals; stars are not treated as quality.

95/100
Documentation28/30
Specificity25/25
Maintenance20/20
Trust signals22/25

Compare before choosing

Related Agent Skills and source variants

These links are selected from shared tasks, functions, stacks, platforms, and same-name variants. Compare the source owner, documentation, permissions, and maintenance signals.

mle-workflow by affaan-m

Production machine-learning engineering workflow for data contracts, reproducible training, model evaluation, deployment, monitoring, and rollback. Use when building, reviewing, or hardening ML systems beyond one-off notebooks.

simpy by k-dense-ai

Build, inspect, test, and analyze bounded process-based discrete-event simulations with SimPy, including events, resources, interrupts, monitoring, replications, warm-up, and reproducible output analysis.

suede-code-grader by JasonColapietro

Give a blunt A-F ship grade for a code change across correctness, security, data, UX, verification, and deploy readiness. Use for a grade, not a findings review.

brand-landingpage by wshobson

Brand-first landing page designer — runs a brand-identity interview (colors, typography, shape language), then generates and iterates on a polished landing page via Stitch with deployment-ready HTML. Use when the user asks to create, design, or build a landing page, homepage, or marketing page and has no established visual direction. Skip when they have a design mockup, need a dashboard or app UI, are working at component level, building a multi-page app, or restyling with known design tokens —

flowstudio-power-automate-build by github

Build, scaffold, and deploy Power Automate cloud flows using the FlowStudio MCP server. Your agent constructs flow definitions, wires connections, deploys, and tests — all via MCP without opening the portal. Load this skill when asked to: create a flow, build a new flow, deploy a flow definition, scaffold a Power Automate workflow, construct a flow JSON, update an existing flow's actions, patch a flow definition, add actions to a flow, wire up connections, or generate a workflow definition from

View original Skill.mdThis page is parsed directly from the repository SKILL.md without editorial rewriting. Collected: Jul 28, 2026 · about 2 min

terragrunt

When to use

Use this skill when working with Terragrunt configurations (.hcl files), managing environment-specific settings, or orchestrating multi-module deployments.

Procedure: Write Terragrunt config

  1. Read the root.hcl in the target environment (environments/pro/root.hcl or environments/sta/root.hcl).
  2. Check existing terragrunt.hcl files in sibling directories for patterns.
  3. Read the target module's variables.tf to understand required inputs.

Project structure

environments/
├── pro/
│   ├── root.hcl                        # Root config (backend, providers)
│   ├── core/
│   │   ├── terragrunt.hcl              # Core module config
│   │   └── {service}.yaml               # Module-specific variables
│   ├── {service}/
│   │   ├── terragrunt.hcl              # Service module config
│   │   └── {service}.yaml              # Service-specific variables
│   └── ...
└── sta/
    ├── root.hcl
    └── ...

Root configuration (root.hcl)

The root HCL defines shared settings for all modules in an environment:

Environment variables

locals {
  env_files = merge(
    yamldecode(file(".env.yaml")),           # Base env vars
    try(yamldecode(file(".env.local.yaml")), {})  # Local overrides
  )
  env = { for k, v in local.env_files : k => get_env(k, v) }
}
  • .env.yaml — committed, shared environment config
  • .env.local.yaml — gitignored, local overrides (AWS profiles, etc.)
  • Real environment variables take precedence over file values.

Remote state

remote_state {
  backend = "s3"
  config = {
    bucket         = "${local.env.aws_account_name}-terraform-remote-state"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    dynamodb_table = "${local.env.aws_account_name}-terraform-remote-state"
    profile        = local.env.aws_profile
    region         = local.env.aws_region
    encrypt        = true
  }
}

Provider generation

Providers are auto-generated by Terragrunt (not manually written):

generate "provider" {
  path      = "provider-aws.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "aws" {
  allowed_account_ids = ["${local.env.aws_account_id}"]
  profile             = "${local.env.aws_profile}"
  region              = "${local.env.aws_region}"
}
EOF
}

Terraform binary

terraform_binary = "terraform"  # Explicitly NOT OpenTofu

Module configuration (terragrunt.hcl)

Each module directory contains a terragrunt.hcl that:

  1. Loads module-specific variables from a YAML file
  2. Includes the root config for backend and providers
  3. Points to the Terraform module source
  4. Declares dependencies on other modules
  5. Passes inputs by merging dependency outputs with local variables

Example pattern

locals {
  project = yamldecode(file("{service}.yaml"))
}

include {
  path   = find_in_parent_folders("root.hcl")
  expose = true
}

terraform {
  source = "../../..//modules/{service}"
}

dependency "core" {
  config_path = "../core"
}

inputs = merge(
  dependency.core.outputs,
  local.project
)

Conventions

Variable files

  • Use YAML files (not HCL) for module-specific variables.
  • Name them after the module (e.g., my-service.yaml).
  • Keep them in the same directory as terragrunt.hcl.

Dependencies

  • Use dependency blocks to reference other modules.
  • Core module outputs (VPC, DNS zones, etc.) are passed via dependency.core.outputs.
  • Merge dependency outputs with local variables in inputs.

Additional providers

Some modules need extra providers (e.g., New Relic). Generate them in the module's terragrunt.hcl:

generate "provider_newrelic" {
  path      = "provider-newrelic.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "newrelic" {
  account_id = "${include.locals.env.newrelic_account_id}"
  api_key    = "${get_env("TF_VAR_newrelic_api_key", include.locals.env.newrelic_api_key)}"
}
EOF
}

Development tools

The project uses devbox for tool management:

{
  "packages": ["terragrunt", "awscli2", "terraform@latest"]
}

Quick commands (devbox scripts)

devbox run i           # terragrunt init
devbox run p           # terragrunt plan
devbox run a           # terragrunt apply
devbox run d           # terragrunt destroy

Output format

  1. Terragrunt HCL files with DRY environment configuration
  2. Dependency graph and remote state references

Auto-trigger keywords

  • Terragrunt
  • multi-environment
  • DRY config
  • remote state

Gotcha

  • Terragrunt dependency blocks create implicit ordering — circular dependencies cause cryptic errors.
  • Don't duplicate Terraform variables in terragrunt.hcl — use inputs to pass them through.
  • The model tends to hardcode values that should come from include blocks — use DRY patterns.

Do NOT

  • Do NOT switch to OpenTofu — the project explicitly uses terraform_binary = "terraform".
  • Do NOT hardcode AWS credentials — use AWS profiles from .env.yaml.
  • Do NOT commit .env.local.yaml — it contains local AWS profile overrides.
  • Do NOT modify root.hcl without understanding the impact on all modules.
  • Do NOT remove dependency blocks — they ensure correct apply order.
  • Do NOT use terraform commands directly — always use terragrunt as the wrapper.
Skill path
src/skills/terragrunt/SKILL.md
Commit SHA
0adf49a8ae84
Repository license
MIT
Data collected