Use terraform-module

Generate a Terraform module from a described need, with main.tf, variables.tf, outputs.tf and versions.tf, typed and validated variables, secure defaults (encryption on…

Generate a Terraform module from a described need, with main.tf, variables.tf, outputs.tf and versions.tf, typed and validated variables, secure defaults (encryption on, public access off, least-privilege IAM), a merged tags variable, a basic usage example and a README with inputs and outputs tables.

Reach for it when the user says "write a terraform module for", "create terraform for an S3 bucket / VPC / database", "turn this into a reusable module", or "scaffold infrastructure as code for".

Install it

npx skilldrop-cli install terraform-module                 # Claude Code, your user folder
npx skilldrop-cli install terraform-module --project       # Claude Code, this repo
npx skilldrop-cli install terraform-module --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Infrastructure as code pack: --pack infra-as-code installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Write a terraform module for a private S3 bucket with encryption"
• "Create Terraform for an RDS Postgres instance that other teams can reuse"
• "Turn these copy-pasted resource blocks into a reusable Terraform module with variables and outputs"
• "Scaffold infrastructure as code for a GCS bucket with a README and inputs table"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Review my terraform plan output before I apply it"
• "Review this pull request that changes our Terraform files"
• "Threat model the payments platform we are deploying to AWS"

If another skill answers instead, ask for this one by name: "use terraform-module".

Check what you get

A good result:

• All six pieces exist: versions.tf, variables.tf, main.tf, outputs.tf, a basic usage example, and a README with inputs and outputs tables that match the code.
• Provider and Terraform versions are constrained, with an upper bound on the provider major version.
• Every variable has a type and a description; every variable that can take a bad value has a validation block with a fixable error message.
• Defaults are secure: encryption on, public access off, least-privilege IAM, stateful resources protected from accidental destroy. Insecure options are opt-in variables.
• Tags flow from one tags variable merged with module defaults onto every taggable resource.
• No hard-coded secrets, account IDs, project IDs, regions or ARNs in the module.
• No provider or backend block inside the module.
• The output does not claim the module was validated unless the commands were actually run, and it shows their real output when they were.

See a worked example

• s3 log bucket

Use something else when

• Reviewing a terraform plan before apply: use terraform-plan-review
• Reviewing someone's Terraform pull request for bugs: use pre-merge-review
• Modelling the threats to the system the infrastructure supports: use threat-model
• Estimating what the infrastructure will cost at expected load: use capacity-cost-model
• Moving existing infrastructure or data from one platform to another: use migration-plan

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: capacity-cost-model, migration-plan, pre-merge-review, terraform-plan-review, threat-model

Edit this page on GitHub · View source