HashiCorp Agent Skills: the vendor's own rules for driving Terraform and Packer

What the skills are for: a house style for infrastructure code

The repository is a collection of Agent skills and Claude Code plugins for HashiCorp products, and at the moment it covers two of them, Terraform and Packer. The catalogue in the project documentation lists sixteen skills for Terraform and four for Packer, twenty in total.

A skill here is a set of instructions that an agent loads and follows, so the problem being solved is not a missing API but a missing house style. An agent asked to write or review Terraform will produce syntactically valid code that may ignore every convention the team cares about, and the same is true for a Packer build. Encoding the conventions as skills means they travel with the tool instead of living in a wiki page nobody reads.

The audience is two groups. The first is teams already using Terraform and Packer who also use an agent, and who want the guidance to come from the vendor rather than from a prompt they wrote themselves. The second is the individual engineer experimenting with agents on infrastructure code, who wants a reference implementation of how a vendor structures such a catalogue.

The topics list for the repository contains a single tag, doormat-managed. That is a telling choice of wording. These are rules, and the project's purpose is to make agents behave the way the vendor wants them to behave across the ecosystem, which is a sensible commercial interest and also the reason to read the skills critically rather than accept them wholesale.

The layout: two plugin roots and two marketplace manifests

The repository structure is small enough to read in one screen, and the project documentation includes it verbatim:

agent-skills/
├── .agents/plugins/marketplace.json
├── .claude-plugin/marketplace.json
├── plugins/
│   ├── terraform/
│   │   ├── .claude-plugin/plugin.json
│   │   ├── .codex-plugin/plugin.json
│   │   └── skills/
│   └── packer/
│       ├── .claude-plugin/plugin.json
│       ├── .codex-plugin/plugin.json
│       └── skills/
└── SKILLS.md

Two things stand out. First, there are two marketplace manifests at the root, one for Claude Code and one for the agents directory used by Codex, so the same repository serves both clients. Second, each product directory carries its own plugin manifest for both clients, and the skills themselves sit under a single skills/ directory per product, so the same skill directory serves Claude Code, Codex, GitHub Copilot, Cursor, Opencode and the rest.

That last point is the design decision with the most reach. The install instructions name GitHub Copilot, Claude Code, Opencode, Cursor and IBM Bob among the supported tools, and a single skill path is what gets installed, so the skills are not tied to one agent runtime. The tree also shows that the skills are plain directories rather than a compiled artefact, which is what makes a single skill installable on its own.

The catalogue itself is SKILLS.md, which the documentation points to for the complete list of skills and the lifecycle status of each. Lifecycle status per skill is the detail worth noticing, because it means the catalogue distinguishes between a skill that is current and one that is being retired, and that distinction is only visible in that file.

Installing a single skill with the skills CLI

The narrowest install is one skill, and the tooling for it is a Node package invoked with npx. Listing what the repository offers is a single command:

npx skills add hashicorp/agent-skills

Installing one skill by path is the same command with a path appended, and the documentation gives an example for each product:

npx skills add hashicorp/agent-skills/plugins/terraform/skills/terraform-style-guide
npx skills add hashicorp/agent-skills/plugins/packer/skills/aws-ami-builder

The terraform-style-guide and aws-ami-builder names are the two concrete skills the documentation uses, and they are a fair sample of the catalogue: one is about how Terraform code should be written, the other about building an AMI with Packer. The path is part of the identifier, which is why the migration described later in this article matters for anyone who wrote the paths down.

The documentation notes that every supported path appears in SKILLS.md, so the file to consult before installing anything is the catalogue rather than a directory listing. The path convention of product, then category, then skill name was in place before the migration, and the migration changed the first two segments.

What the install actually does to your project is not described in the documentation, so it is worth checking the files the command writes before running it across a repository, particularly if you are working inside a directory that is under an organisation's policy about agent configuration.

Installing the product bundle in Claude Code and Codex

The bundle is the other route, and it is a different shape of decision. For Claude Code, the install is three commands: add the repository as a marketplace, then install the product plugin.

claude plugin marketplace add hashicorp/agent-skills
claude plugin install terraform@hashicorp
claude plugin install packer@hashicorp

The plugin identifiers follow a name@publisher pattern, and the publisher is hashicorp. The two bundles are terraform and packer, matching the skill counts in the catalogue.

Codex works differently, and the documentation is explicit about it: you add the repository's .agents/plugins/marketplace.json as a repository marketplace, then install the terraform or packer plugin in Codex. Both marketplaces expose the same product bundles and the same skill directories, so the two clients see an identical catalogue even though the manifest and the install command differ.

The difference in approach between the two routes is worth stating clearly, because it determines how much context an agent carries. Installing a single skill gives you one rule set, narrowly scoped, which is the right choice when you only want the Terraform style guide and nothing else. Installing the product bundle gives you the whole set of sixteen or four skills for that product, which is the right choice when you want the vendor's complete view of how that product should be used, at the cost of a larger body of instructions in the agent's context.

The legal note at the top of the documentation applies to both routes: your use of a third party MCP client or LLM is subject to that provider's terms alone, and IBM states that it is not responsible for the performance of those third party tools and may be unable to support issues caused by them.

The migration: legacy plugin identifiers no longer resolve

The documentation carries a migration section, and it is the part to read before upgrading an existing setup.

The product plugin bundles replace six legacy plugin identifiers: terraform-code-generation, terraform-module-generation, terraform-provider-development, terraform-policy-code, packer-builders and packer-hcp. Those names no longer work. The replacement is terraform@hashicorp for the Terraform bundle and packer@hashicorp for Packer, so an existing installation has to be replaced rather than upgraded in place.

Individual skill paths moved too. The old form was terraform/<category>/skills or packer/<category>/skills, and the new form is plugins/<product>/skills/<skill-name>. A pinned path in a script, a CI job or a team wiki has to be rewritten.

The repository now organises its twenty skills under the two product plugin roots, plugins/terraform/skills/ and plugins/packer/skills/. So the change is not a rename, it is a reorganisation: the category segment is gone from the path and the product moved under a plugins/ prefix.

For a team that installed the legacy plugins, this is an operational chore rather than a technical one, but it is one that has to be done across every machine and every automation that installs the plugin, and the documentation is the only place that lists the mapping.

Governance: who can change a skill, and who answers for it

The governance section of the documentation is the most revealing part of this repository, and it is worth reading in full before you build a workflow on top of these skills.

Contributions are restricted to HashiCorp-internal contributors until further notice. That single sentence is the defining constraint of the project. Despite the open source licence, you cannot submit a pull request to fix a skill that is wrong for your setup, or add a skill for a product the vendor has not shipped. The skills are published, versioned and reviewable, but not community maintained.

Around that restriction, the repository has the apparatus of a serious project. CONTRIBUTING.md holds the contribution guidance, SECURITY.md covers how to report security issues or data sensitivity concerns specific to the skills, SUPPORT.md defines the repository support boundaries, SUPPORTED_MODELS.md defines the current Anthropic and OpenAI supported model matrix, and CODEOWNERS records canonical ownership and review routing for skills. A CHANGELOG.md and an AGENTS.md are also present, along with a .copywrite.hcl file for attribution tooling and a scripts/ directory.

Two of those documents are about boundaries rather than content. SUPPORT.md tells you where the support line sits, and SUPPORTED_MODELS.md tells you which models the skills are validated against, which matters because a skill is a prompt and prompts behave differently across model versions.

The practical implication is that you are consuming a vendor product that happens to be readable and permissively licensed, not a community catalogue. That is not a criticism. It is the same arrangement as an official style guide, and it is a reasonable thing to adopt, as long as you know you cannot change it.

Licence, releases and what a team gets out of this

The licence is MPL-2.0, which is a file level copyleft licence. It lets you use, modify and redistribute the skill files, and if you modify a file you must publish that modified file under the same terms. The practical reading is that you can vendor the skills into your own repository and adjust them for internal use, but you cannot take a modified skill and keep it closed.

There is a single release so far, v1.0.0, published on 2026-08-04, and the repository is not archived with the last push on 2026-10-05. So the catalogue is at a stable version, recently touched, and the versioning will presumably be a simple one. The catalogue also has no homepage outside the repository, and the skills are consumed through a client, not a website.

What a team actually gets is a set of conventions that HashiCorp already believes in, distributed in a form an agent can consume. That has real value for the common failure mode, which is an agent producing Terraform that works but is not written the way the team would write it, and it is the vendor's own opinion rather than a community consensus, which cuts both ways.

The test before you adopt is narrow and concrete. Read SKILLS.md, check that the skills your workflow needs are in the catalogue and have a lifecycle status you are comfortable with, read SUPPORT.md and SUPPORTED_MODELS.md to see where support stops, and confirm that the closed contribution policy is compatible with how you run the rest of your infrastructure tooling. If it is, the install is a single command per client, and the skills are versioned in git alongside the code they govern.

Editorial conclusion

Adopt HashiCorp Agent Skills if you want an agent working on your Terraform and Packer code to follow the vendor's own conventions, and you want the rules to be versioned next to your code. Do not expect it to be a community resource: contributions are restricted to HashiCorp-internal contributors, so you cannot patch a skill yourself, and the model support matrix is defined by the vendor rather than by your client. Before you install, read SUPPORT.md and SUPPORTED_MODELS.md to see where the boundary lies, and check the migration notes, because the legacy plugin identifiers no longer resolve and the skill paths have moved under plugins/.

Frequently asked questions

Official sources

1. hashicorp/agent-skills on GitHub
2. Issues
3. License: MPL-2.0
4. README
5. Releases