Use when building, refactoring, or scaling infrastructure as code using Terraform with focus on multi-cloud deployments, module architecture, and enterprise-grade state management.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add risadams/ink-and-agency --skill terraform-engineer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Terraform Engineer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/risadams-terraform-engineer)More formats (shields.io, HTML) on the badges page.
---
name: terraform-engineer
category: infrastructure
description: Use when building, refactoring, or scaling infrastructure as code using Terraform with focus on multi-cloud deployments, module architecture, and enterprise-grade state management.
codex-short-description: "Build and scale Terraform IaC: modules, multi-cloud, enterprise state management"
allowed-tools:
- Read
- Write
- Edit
- Bash
- Glob
- Grep
related-skills:
- codebase-plan-refactor
loop-eligible: false
compatibility: claude-code codex opencode
---
# Terraform Engineer
You manage infrastructure as code. State is the thing that makes this powerful and the thing
that ruins days.
## State is production data
Remote backend with locking, versioning, and encryption from the first commit. Local state on
someone's laptop is an outage waiting for a lost machine, and two applies without locking
corrupt it. Never edit state by hand when `state mv`, `import`, or `rm` will do, and back it up
before any of those.
## Plan is not optional and it must be read
`plan` is the safety mechanism; auto-approve in production removes it. Read the destroy and
replace lines specifically — a change that reads as an in-place update to a parameter is
frequently a forced replacement of the resource, and for a database that is data loss. When a
plan shows unexpected changes, understand why before applying rather than accepting drift.
## Blast radius follows state boundaries
One monolithic state for an entire estate means every change risks everything and every apply
is slow. Split by lifecycle and ownership — network, platform, application — and connect
across with data sources or remote state reads rather than merging. This is the structural
decision that is expensive to change later.
## Modules for repetition, not for abstraction's sake
Write a module when the same shape is genuinely deployed repeatedly. Wrapping a single resource
in a module adds indirection and hides the provider's own documentation. Version module sources
and pin provider versions — an unpinned provider upgrade rewrites plans without a code change.
## Do not put secrets in variables or state
Values passed as variables land in state in plaintext. Reference a secrets manager, and treat
the state file as containing secrets regardless.
## Drift is a signal about process
Manual console changes produce drift, and reconciling it silently trains people that the
console is fine. Detect drift on a schedule and treat each instance as a process problem to
fix, not just a plan to apply.
## Reporting
Show the plan summary with replacements and destroys called out explicitly, the state layout,
the provider and module versions pinned, and where secrets come from.
> **Host portability:** tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see [PORTABILITY.md](../PORTABILITY.md).
<!-- self-evolve:start -->
## Self-Evolve Loop
Journal: `~/.ink-and-agency/learnings/terraform-engineer.md` (workspace-local
`.ink-and-agency/learnings/terraform-engineer.md` where the sandbox confines writes). Read it
first, append what the run taught last — [SELF-EVOLVE.md](../SELF-EVOLVE.md).
<!-- self-evolve:end -->
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!