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.
event4u-app/agent-config
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.
npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/terragrunt"Quick start
Install it or open the source, trigger it with a clear task, then follow the source workflow.
npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/terragrunt"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.
No structured workflow was detected; follow the original SKILL.md below.
Continue to the workflowDirect answers
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.
It is relevant to workflows involving Deployment, Engineering, Operations.
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.
The upstream source does not declare a dedicated Agent platform.
No obvious permission action was detected by the static rules. This is not proof that the Skill is safe.
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
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
Core capabilities
Distilled from the source
About 2 min · 12 sections
Use this skill when working with Terragrunt configurations (.hcl files), managing environment-specific settings, or orchestrating multi-module deployments.
Terragrunt HCL files with DRY environment configuration
Dependency graph and remote state references
Quality breakdown
Based on traceable docs and repository signals; stars are not treated as quality.
Compare before choosing
These links are selected from shared tasks, functions, stacks, platforms, and same-name variants. Compare the source owner, documentation, permissions, and maintenance signals.
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.
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.
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-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 —
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
Use this skill when working with Terragrunt configurations (.hcl files), managing environment-specific settings, or orchestrating multi-module deployments.
root.hcl in the target environment (environments/pro/root.hcl or environments/sta/root.hcl).terragrunt.hcl files in sibling directories for patterns.variables.tf to understand required inputs.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.hcl)The root HCL defines shared settings for all modules in an environment:
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.)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
}
}
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" # Explicitly NOT OpenTofu
terragrunt.hcl)Each module directory contains a terragrunt.hcl that:
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
)
my-service.yaml).terragrunt.hcl.dependency blocks to reference other modules.dependency.core.outputs.inputs.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
}
The project uses devbox for tool management:
{
"packages": ["terragrunt", "awscli2", "terraform@latest"]
}
devbox run i # terragrunt init
devbox run p # terragrunt plan
devbox run a # terragrunt apply
devbox run d # terragrunt destroy
dependency blocks create implicit ordering — circular dependencies cause cryptic errors.inputs to pass them through.include blocks — use DRY patterns.terraform_binary = "terraform"..env.yaml..env.local.yaml — it contains local AWS profile overrides.root.hcl without understanding the impact on all modules.dependency blocks — they ensure correct apply order.terraform commands directly — always use terragrunt as the wrapper.