Role: Senior Cloud Architect & Terraform Expert (Dr.JOY Vietnam)
## Bối cảnh (Context)
Bạn là một chuyên gia DevOps/Cloud Architect giàu kinh nghiệm đang làm việc tại Dr.JOY Vietnam. Nhiệm vụ chính
Use when implementing infrastructure as code with Terraform across AWS, Azure, or GCP. Invoke for module development, state management, provider configuration, multi-environment workflows, infrastructure testing.
Automate AWS infrastructure deployment using Terraform with security scanning, best practices, and iterative development. Use when user says "create infrastructure", "deploy with Terraform", "run Checkov scan", "validate Terraform", or "debug deployment failure". Do NOT use for reading or explaining existing Terraform code, answering general Terraform questions, or CloudFormation/CDK-only workflows.
Parse and analyse terraform plan plain-text output to classify resource changes, detect unintended mutations, and produce structured reports. Use when reviewing terraform plan output for import safety, drift detection, or plan validation. Triggers on "parse plan", "plan analysis", "plan diff", "classify changes", "import validation", "zero-change check", or any post-hoc analysis of terraform plan stdout.
Authors and reviews Terraform configuration for the security properties that formatting and validation do not cover, meaning state and secret exposure, least-privilege execution identity, provider and module supply chain, sensitive variables and outputs, and policy-as-code enforcement, verified through the target repository's own fmt, validate, tflint, and configuration-scanning loop rather than from the edit alone. Use when creating or modifying Terraform configuration, backends, or provider blocks, and when reviewing state handling, secrets, execution credentials, module sources, or version pinning.
Blueprint for production AWS infrastructure with Terraform and GitHub Actions, proven on a Django and ECS system. Covers the environment-and-module layout, the reversible feature-toggle pattern (count flags that tear a subsystem to zero cost and back), S3 state with native locking, OIDC for CI auth with no static keys, the plan-before-apply discipline the source workflow lacked, the safe ECS deploy ordering (register, migrate as a one-off, abort on failure, then roll), least-privilege IAM with instance and task roles, the security posture for an app behind a TLS-terminating load balancer, secrets through SSM, private-by-default networking, and the SSM and mesh access model. Includes explicit do's and don'ts and the gotchas that bit in production. Use when building, reviewing, or operating this kind of infrastructure.
Terraform / OpenTofu conventions (file layout with a mandatory `data.tf` and one file per component, naming, typed and documented variables, pinned providers, secrets out of the state, `terraform test`, pre-commit hooks, trivy `AVD-xxxx`). TRIGGER when: creating or editing any `.tf`, `.tfvars`, `.tftest.hcl`, or `.terraform.lock.hcl` file; adding a resource, data source, variable, output, local, module or provider; setting up pre-commit or CI for a stack that contains Terraform; user asks about Terraform/OpenTofu layout, state, providers, modules, plan/apply, tflint, terraform-docs or tfsec/trivy findings in this repo. SKIP when: no HCL is being written or edited and the user isn't asking about Terraform/OpenTofu tooling.
Comprehensive guide for Terraform code style, formatting, and best practices based on HashiCorp's official standards and Azure Verified Modules (AVM) requirements. Use when writing or reviewing Terraform configurations, formatting code, organizing files and modules, establishing team conventions, managing version control, ensuring code quality and consistency across infrastructure projects, or developing Azure Verified Modules.
Generate Terraform HCL code following HashiCorp's official style conventions and best practices. Use when writing, reviewing, or generating Terraform configurations.
Design and create Terraform modules from real infrastructure requirements. Use when asked to create a Terraform module, build a module from a requirement, turn repeated Terraform into a module, design module inputs and outputs, review whether a Terraform pattern should become a module, refactor existing Terraform into a reusable module, or assess whether a module is over-abstracted. Covers Azure-focused modules with KISS/DRY principles, module boundary definition, interface design, and practical file structure generation. Do NOT use for general Terraform coding with no module boundary, provider version upgrades (use terraform-provider-upgrade skill), or non-Terraform IaC.
Writes and organizes Terraform under four non-negotiable structural rules: everything in first-party modules designed for reuse, environments separated as folders (never workspaces), zero community modules, and provider versions always looked up in the registry before being written. Use whenever the user says "write the terraform", "create the infrastructure as code", "provision this with terraform", "set up the terraform project structure", "organize this terraform", "review my terraform", "create the module", "add a new environment", or points at a repository with .tf files wanting to create or change infrastructure. Trigger it also when the task is just creating or editing a single .tf file — the wrong structure is born precisely out of "just a quick main.tf" — and when the request mentions a community module (terraform-aws-modules, Azure/, terraform-google-modules), because the right move there is to write the equivalent first-party module. Applies to any cloud or provider. Do NOT trigger for: plain Kubernetes/Helm manifests (no Terraform involved), Pulumi, CloudFormation or CDK, and debugging cloud API errors (permissions, quota, service limits) that are not a matter of code structure.
Interact with HCP Terraform / Terraform Cloud / Terraform Enterprise using the tfctl CLI. Full API coverage. Use for ANY HCP Terraform or Terraform Cloud or Terraform Enterprise question or action — listing workspaces, starting/diagnosing runs, reading vars, modifying resources, calling API operations.
Using the Materialize Terraform provider to manage Materialize resources declaratively. Covers clusters, sources (Kafka, Postgres, MySQL, SQL Server), sinks (Kafka, Iceberg), connections, materialized views, indexes, tables, roles, grants, secrets, network policies, and cloud-only resources (users, SSO, SCIM, app passwords). Use this skill whenever the user asks about writing Terraform for Materialize, creating or configuring Materialize resources with Terraform, importing existing Materialize objects into Terraform state, configuring the Materialize provider for Cloud or self-managed, setting up RBAC or grants via Terraform, creating connections or sources in Terraform, or troubleshooting Terraform plan/apply issues with Materialize resources. Also trigger when the user mentions materialize_cluster, materialize_source_kafka, materialize_connection_postgres, or any other materialize_* resource type.
A folder with a SKILL.md file: a name, a description of when to use it, and instructions. Claude loads a skill only when the task matches its description.
How do I use one I find here?
Copy the folder into your project's .claude/skills/ directory, or into your own skills folder to use it everywhere.
What do the warnings mean?
We read each file for commands that read secrets, delete things or pipe downloads into a shell, and say so before you copy it. No warning is not a promise that a file is safe.
Which skills worked for people?
Open a skill to see its discussion. Reports from people and their agents are coming.
kumaran-isSkill
