terraform-skill: Terraform and OpenTofu guidance packaged as an AI agent skill
Terraform & OpenTofu Skill for AI Agents - testing, modules, CI/CD, and production patterns
At a glance
- What is it?
- A best-practices skill for AI coding agents that covers Terraform and OpenTofu testing, module structure, state backends, and CI/CD. It is useful if your agent writes infrastructure code and you want its defaults to match established Terraform conventions, but it is documentation in skill form, not a tool that runs anything.
- Who is it for?
- Adopt it if your team already writes Terraform or OpenTofu and your agent keeps producing module layouts, state backend configs, or CI workflows that drift from what you use. Skip it if you need something that executes plan or apply, or if you cannot accept the licence terms, since the repository ships an Apache 2.0 badge while the metadata reports NOASSERTION.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 75 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between an agent that writes HCL and one that writes maintainable Terraform
An AI coding agent will happily produce Terraform. What it produces by default tends to be a single flat main.tf with resources in the order they were requested, no variables file, no outputs, and no tests. That is valid HCL and it will often apply cleanly. It is also the shape of code that becomes unmanageable the moment a second environment or a second team touches it. The problem terraform-skill addresses is not syntax. It is the set of conventions that experienced Terraform practitioners apply without thinking: where module boundaries go, how versions are pinned, which backend holds state, how tests are structured.
The repository describes itself as a best-practices skill for Terraform and OpenTofu, aimed at AI coding agents including Claude Code, Cursor, Copilot, Gemini CLI, OpenCode, Codex, and Kiro. The audience is therefore not people learning Terraform. It is people who already know what good Terraform looks like and want the agent working beside them to produce that shape rather than a plausible-looking alternative. The README states that AWS, Azure, and GCP are all first-class, with AWS as the default in examples, and that asking for the Azure or GCP equivalent of a pattern causes the skill to map it.
What the skill actually contains: decision matrices, not generated code
The README lists six content areas. Testing frameworks include a decision matrix for native tests versus Terratest, plus workflows split into static, integration, and E2E. Module development covers structure and naming conventions, versioning strategies, and the split between public and private module patterns. State management covers remote backends (S3, Azure, GCS, Terraform Cloud), locking and security, multi-team state isolation, and migration and recovery procedures. CI/CD covers GitHub Actions workflows, GitLab CI examples, cost optimization, and compliance automation. Security and compliance covers Trivy and Checkov integration and policy-as-code patterns. A quick reference section holds decision flowcharts, DO versus DON'T patterns, and cheat sheets.
The important structural point is that this is guidance material, not an executable. The skill does not run terraform plan, does not call a provider, and does not validate the HCL it helps produce. The decision matrix for native tests versus Terratest is the clearest example of the design intent: rather than picking a testing framework for you, it gives the agent criteria to pick one, which means the output depends on how well the agent applies those criteria to your context. That is a reasonable design for a skill, but it shifts the failure mode from "wrong tool chosen" to "right tool chosen for the wrong reasons" if your context is unusual.
Installation paths differ per host, and one of them will bite you
The universal path is a single command that works with any Agent Skills-compatible tool:
npx skills add https://github.com/antonbabenko/terraform-skill
Claude Code uses a marketplace instead. The README is explicit that you add antonbabenko/agent-plugins and then install terraform-skill from it:
/plugin marketplace add antonbabenko/agent-plugins /plugin install terraform-skill@antonbabenko
The README warns twice, for both Claude Code and Codex, not to add antonbabenko/terraform-skill as a marketplace as well, because both use the same marketplace name and will clash. That is the single most likely installation mistake here, and it is a naming collision rather than a functional limitation.
Other hosts have their own routes. Gemini CLI uses gemini extensions install with the repository URL, updated via gemini extensions update terraform-skill. Cursor, Copilot, OpenCode, Codex, and Kiro mostly work by cloning the repository into a discovery directory: ~/.cursor/skills/terraform-skill, ~/.copilot/skills/terraform-skill, ~/.agents/skills/terraform-skill, or ~/.kiro/skills/terraform-skill. Autohand Code expects the inner skills/terraform-skill directory copied into ~/.autohand/skills/ or .autohand/skills/. Antigravity uses a symlink into ~/.gemini/config/skills/. A manual symlink into ~/.claude/plugins/ is also documented, and the README notes that edits to the clone are picked up live, which is convenient if you want to fork the guidance.
Kiro has a second mode, as a Kiro Power, added through the Powers panel from the GitHub URL. The README states that installing it this way also registers the optional read-only HashiCorp terraform-mcp-server from mcp.json under the Powers section of ~/.kiro/settings/mcp.json, and that the guidance works without it. POWER.md is generated from skills/terraform-skill/SKILL.md, so the content is shared rather than duplicated.
The companion plugin is where the token argument lives
The README recommends installing code-intelligence alongside terraform-skill, from the same marketplace:
/plugin marketplace add antonbabenko/agent-plugins /plugin install code-intelligence@antonbabenko
The stated division of labour is that code-intelligence holds the general, any-language rules for finding things in code (when to use a language server, plain text search, or fuzzy search; how to anchor a lookup to a position; what to do when a tool fails; saying so when one tool is swapped for another), and terraform-skill is the Terraform-specific version of those rules. The two stated benefits are fewer tokens, because the rules live in one place and load when needed instead of being repeated in every language skill, and more accuracy, because definitions and references are found by meaning rather than by text match.
This is a claim about how the skill is organised rather than a measured result, and the README does not present numbers for it. Treat the token argument as a design rationale. If you are already running several language skills, the consolidation argument is plausible. If you run one, the companion adds a second install for a benefit you may not notice.
Where an agent skill stops being the right tool
The clearest limitation is that nothing here is enforced. A skill shapes what the agent generates; it does not fail a build. If your problem is that a developer committed a state file or opened a security group to 0.0.0.0/0, terraform-skill will not catch it. The README points at Trivy and Checkov integration and policy-as-code patterns, but those are guidance the agent can apply when writing configuration, not a scanner wired into your pipeline. For enforcement you need the scanners themselves, plus whatever policy engine you already run.
The second limitation is version drift. The badges state Terraform 1.0+ and OpenTofu 1.6+, and the repository has moved through v1.16.0, v1.17.0, and v1.17.1 in roughly a month. That release cadence suggests active maintenance of the guidance, but it also means the content can be ahead of or behind the specific provider versions your team pins. Nothing in the material describes a compatibility matrix between skill versions and Terraform or OpenTofu releases, so there is no documented way to know whether the guidance you installed matches the version you run.
The third limitation is the licence. The README displays an Apache 2.0 badge and links to a LICENSE file, while the repository metadata reports NOASSERTION. Those two signals disagree. Apache 2.0 is permissive and would normally be unproblematic for internal use, but if the actual licence text differs from the badge, the terms you are accepting are the ones in the file, not the ones in the badge. Read the LICENSE file before you depend on it. This is a factual discrepancy in the repository, not legal advice.
Against writing your own prompt or style guide
The obvious alternative is a hand-written prompt or an internal style guide pasted into the agent's context. The difference is in coverage and upkeep. A prompt you write covers the conventions your team has already argued about: naming, tagging, module layout. terraform-skill covers areas a team prompt usually omits, such as the native-tests-versus-Terratest decision, state migration and recovery procedures, and multi-team state isolation. It also covers three cloud providers, which a team prompt rarely does because most teams standardise on one.
The trade-off runs the other way on specificity. A team prompt encodes your account structure, your backend bucket naming, your tag schema, and your approval process. terraform-skill encodes general practice, and the README frames it as guidance that maps to Azure or GCP when asked. It has no knowledge of your organisation. If your conventions diverge from mainstream Terraform practice, the skill will push the agent toward the mainstream answer and you will spend time correcting it. The two are not mutually exclusive: the manual install path symlinks a local clone into ~/.claude/plugins/, and the README notes edits to the clone are picked up live, so forking the skill and layering your own conventions on top is a supported route rather than a workaround.
Maintenance cost and what a verification pass looks like
Installation is cheap. Updating depends on the host: Codex and Antigravity use git pull inside the clone, Gemini CLI has gemini extensions update terraform-skill, and the marketplace route updates through the plugin manager. The manual symlink approach means updating is a pull in the clone directory, with the caveat that live edits are picked up, so a fork and upstream updates can conflict.
The real ongoing cost is reviewing what the agent produces. The README's verification step is to install and then ask for something concrete:
"Create a Terraform module with testing for an S3 bucket"
That is a reasonable smoke test, and it exercises module structure and the testing decision matrix at once. What it does not tell you is whether the agent picked native tests or Terratest for a defensible reason in your context. Do that once per repository before you rely on the skill, and compare the module layout, the variable and output naming, and the chosen test framework against what your team already ships. If the output matches, the skill is doing its job. If it does not, the mismatch is easier to fix in the skill's guidance than in every future pull request.
Editorial conclusion
Adopt it if your team already writes Terraform or OpenTofu and your agent keeps producing module layouts, state backend configs, or CI workflows that drift from what you use. Skip it if you need something that executes plan or apply, or if you cannot accept the licence terms, since the repository ships an Apache 2.0 badge while the metadata reports NOASSERTION. Before rolling it out, install it in one repository, ask the agent for an S3 bucket module with tests, and check the generated module layout and testing choice against your own conventions.
Community notes