Infrastructure as code pack reference

Every skill in the Infrastructure as code pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

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.

Skills

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.

Tier standard · v0.1.1 · SKILL.md · skill page

Use 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".

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.

Hands off to: terraform-plan-review when the module has been planned from examples/basic or a real caller.

Not for:

• 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

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.

Tier heavy · v0.1.2 · SKILL.md · skill page

Use it 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".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Every destroy and replace is listed by full address with its cause. The attribute forcing the replacement is named, from replace_paths or # forces replacement.
• Every stateful resource that is destroyed or replaced says what data is at risk and what recovers it. Missing backups are called out, not assumed.
• Access changes quote the before and after of the rule or statement, and say whether access widens or narrows.
• Drift is reported separately from intended change, with whether the plan reverts it.
• Out-of-scope changes are listed against the user's stated intent.
• Exactly one verdict, with the reasons behind it and a numbered "Before you apply" list.
• No invented resources or attributes. Every address and attribute in the review appears in the plan the user supplied.
• No secret values are echoed from the plan, even when the plan contains them.

Hands off to: migration-plan when a stateful resource must be replaced and its data moved; runbook-generator when the plan is approved and the apply needs a step-by-step procedure.

Not for:

• Reviewing the HCL or application code diff in a pull request: use pre-merge-review
• Writing a new Terraform module: use terraform-module
• Planning a data or platform migration end to end, with cutover and rollback: use migration-plan
• Estimating what the new infrastructure will cost: use capacity-cost-model
• Writing the step-by-step apply and rollback procedure for on-call: use runbook-generator

Included from core

Installed with this pack. Details: Core pack reference.

• 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.
• 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.
• 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."
• 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.
• 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.

Edit this page on GitHub · View source