From gaia-ops
Use when creating, modifying, or reviewing Terraform or Terragrunt configuration files
npx claudepluginhub metraton/gaia --plugin gaia-opsThis skill uses the workspace's default tool permissions.
Project-specific conventions. Use values from your injected project-context — never hardcode project IDs, regions, or account identifiers.
Triggers research for existing libraries, tools, and patterns before coding new features. Searches npm, PyPI, MCP/skills, GitHub; evaluates matches and decides adopt/extend/build.
Audits cross-stack repos (C++/Android/iOS/Web), classifies files as project/third-party/artifacts, detects embedded libraries, assigns module verdicts, generates interactive HTML reports.
Reorganizes X and LinkedIn networks: review-first pruning of low-value follows, priority-based add/follow recommendations, and drafts warm outreach in user's voice.
Share bugs, ideas, or general feedback.
Project-specific conventions. Use values from your injected project-context — never hardcode project IDs, regions, or account identifiers.
For HCL examples (remote state, component structure, labels, outputs), read reference.md in this directory.
Every project organizes Terraform differently. Before creating any file, discover how THIS project does it.
tf_modules/, modules/,
terraform/, or similar. The name varies — what matters is whether
reusable modules exist and where they live.source =
lines. Do they reference local modules? Registry modules? A mix?If the project has reusable modules for similar resource compositions (e.g., a cloud-sql module that composes instance + database + user + secrets), and your new resource follows a similar composition pattern, create a reusable module. If it's truly one-off glue with no reuse potential, inline is acceptable — but check first, because most projects lean one way.
The structure below is a common starting point, not a prescription. If the codebase uses a different layout, follow the codebase.
terraform/
└── [module-name]/
├── main.tf # Resource definitions
├── variables.tf # Input variables
├── outputs.tf # Output values (snake_case, with descriptions)
└── provider.tf # Provider config (if module-level)
features/infra/[env]/
├── terragrunt.hcl # Root: remote state config
└── [component]/
└── terragrunt.hcl # Component: inputs + dependency references
| Resource | Pattern | Notes |
|---|---|---|
| Network/VPC | {app}-{env}-vpc | From context: project + env |
| Cluster | {app}-{env}-cluster-{n} | Match context cluster_name |
| Database | {app}-{env}-{engine}-instance | Engine: postgres, mysql |
| Secret | {service}-secret | Matches app service name |
| Service Account | {resource}-sa | Scope: resource it serves |
../../../../../terraform//{module-name}tfr:///terraform-aws-modules/{module}/aws?version=x.y.zlatest, never unpinnedterragrunt commands for all environment operations; raw terraform is acceptable for module development and testing onlydependency.x.outputs.y~> for providersdescription fieldvalidate and plan to work offlineUse WebFetch when a resource or attribute is unknown or ambiguous. Do not use WebFetch to discover patterns — the codebase always wins over external docs.
| Need | URL |
|---|---|
| Google provider resources | https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/{resource} |
| Terragrunt config blocks | https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes |