Infrastructure as code
- When to use it
- Terraform you can hand to another team and plans you can trust before apply: reusable modules with secure defaults, and a plan review that catches destroys, data loss, access widening and drift.
- Covers
- Design the system (1), Run and recover the service (1)
- Where you decide
- No gated loop of its own; the skills run one at a time.
- Size
- 7 skills · 0 loops
20 to 45 minutes a session
npx skilldrop-cli install --pack infra-as-code
Installs 7 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack infra-as-code
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install infra-as-code@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack infra-as-code --ide cursor
Start here: Write a module, then review its plan before the first apply
Paste this into your agent:
Write a Terraform module for an S3 bucket that stores our access logs for a year. Several teams will call it. Then, once I've run terraform plan on the example, review the plan before I apply.
- Before you start
- A Terraform project or a described piece of infrastructure
- Terraform installed locally if you want to validate and plan the result
- How to tell it worked
- terraform-module writes versions.tf, variables.tf, main.tf, outputs.tf, a basic example and a README with inputs and outputs tables, with encryption on and public access off by default. terraform-plan-review returns SAFE TO APPLY, APPLY WITH CARE or DO NOT APPLY with every destroy and replace named.
- If nothing happens
- If terraform validate fails, paste the error back and ask terraform-module to fix that file. If terraform-plan-review does not activate, ask for it by name ("use terraform-plan-review") and give it the output of terraform show -json tfplan.
A typical session
When: You need new infrastructure as a reusable Terraform module, or you have a plan in front of you and want to know whether it is safe to apply. About 20 to 45 minutes.
You bring:
- what the infrastructure is for and which cloud it runs on
- who will call the module
- the output of terraform plan, ideally terraform show -json tfplan
- one sentence on what the change is meant to do
-
- You
- Describe the need, the cloud and the callers.
- You get
- A module with versions.tf, typed and validated variables, secure defaults, a tags variable, a basic example, a README, and the commands to check it.
-
- You
- Run terraform plan, save it with terraform show -json, and hand it over with the intent of the change.
- You get
- Counts, every destroy and replace with its cause, stateful and access changes, drift, out-of-scope changes and a verdict.
- You decide
- Apply, apply after the listed checks, or fix the code and re-plan.
-
- You
- Optionally, run it on the module README before you publish the module to other teams.
- You get
- Severity-tagged findings on gaps and unclear inputs, with a fix for each.
You end with: A reusable module with safe defaults, and a reviewed plan with a clear apply decision.
Compare Infrastructure as code with another pack
Skills in this pack (2)
- 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, public access off, least-privilege IAM), a merged tags variable, a basic usage example and a README with inputs and outputs tables. Use 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". standard
- terraform-plan-review Review a terraform plan before apply, from the plan text or terraform show -json output. Flags every destroy and replace with the attribute forcing it, changes to stateful resources such as databases, buckets and volumes, IAM and security-group widening, drift nobody made in code, and changes outside the intended scope, then gives a SAFE TO APPLY, APPLY WITH CARE or DO NOT APPLY verdict with reasons. Use when the user pastes a plan, says "review this terraform plan", "is this plan safe to apply", "why is terraform replacing my database", or "check the plan before I apply". heavy
Included from core (5)
- brief-intake Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- context-graph Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- council-review Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- doc-critique Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- output-hygiene Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard