Terraform Skill Pack

What This Pack Covers

Two skills, both centered on reading terraform plan output correctly before anything actually changes: one flags destructive changes hiding inside a plan, and one surfaces drift between Terraform’s recorded state and the real infrastructure. Both are a clean example of the Skill Engineering idea that a skill’s real value can be almost entirely in interpreting a tool’s output correctly, not in producing anything new itself.

Skill 1: terraform-plan-review

---
name: terraform-plan-review
description: Reviews terraform plan output for destructive changes — resource replacement, deletion, and changes that force a replace rather than an in-place update. Use before running terraform apply, or when the user asks if a plan is safe.
metadata:
  version: "1.0.0"
compatibility: Requires a terraform plan output (via terraform plan or terraform show) to review
---

## Reading the plan

Terraform marks each resource action explicitly — look for these symbols
in the plan output:

- `+` create — generally low risk, a new resource
- `-` destroy — flag every one explicitly; confirm this is intentional
- `-/+` destroy and re-create (a "replace") — flag as high risk; this
  means the resource will be deleted and a new one created, which for
  stateful resources (databases, volumes) can mean data loss
- `~` update in place — generally lower risk, but check what's changing

## Review checklist

1. List every `-` and `-/+` resource explicitly, with its resource type
   and name — do not let a destroy or replace pass by silently inside a
   larger plan with many other changes.
2. For any `-/+` on a stateful resource type (databases, storage volumes,
   persistent disks), flag this as requiring explicit confirmation that
   data loss is acceptable or that a migration plan exists.
3. Note the total resource count affected — a plan touching far more
   resources than the stated change would suggest is worth a second look
   before applying, since it may indicate an unintended dependency change.

## On confirmation

Never suggest running `terraform apply` in the same response that
identifies a destroy or replace, without explicit user confirmation that
the destructive change is intended.

Pattern: Validator — checking structured plan output against risk criteria, exactly the pattern from Skill Design Patterns, applied to a domain where the validator’s entire job is correctly parsing another tool’s output rather than evaluating free-form content.

Skill 2: terraform-drift-detect

---
name: terraform-drift-detect
description: Surfaces drift between Terraform's recorded state and actual infrastructure, using terraform plan's detected differences when no code changes are pending. Use when the user asks if infrastructure has drifted, or wants to check for manual changes made outside Terraform.
metadata:
  version: "1.0.0"
---

## What drift looks like

Run `terraform plan` with no pending code changes. Any resource Terraform
reports as needing an update or replacement, despite no `.tf` file having
changed, indicates the real infrastructure no longer matches Terraform's
recorded state — someone or something changed it outside of Terraform.

## Reporting drift

For each drifted resource, report:
1. What Terraform expects the value to be (from state/code)
2. What Terraform detected the actual value as
3. A likely cause where determinable — a manual console change is the
   most common cause, but a separate automation process is also possible

## Constraints

Do not resolve drift automatically. Reconciling drift means choosing
whether to update the code to match reality or force reality back to
match the code — a decision with real consequences that needs a human
to make, not this skill.

Pattern: Validator, but notice the constraint here is different in kind from the previous skill’s: terraform-plan-review refuses to auto-apply; this one refuses to auto-decide which side of a discrepancy is correct. Both are the same underlying discipline from Skill Engineering — state the boundary of what the skill will and won’t do on its own — applied to two different kinds of judgment call.

Why Both Skills Stop at “Report,” Never “Fix”

Neither skill in this pack takes any action against real infrastructure — both are scoped entirely to reading and reporting on terraform plan output. This mirrors the Kubernetes pack’s read-only boundary, for the same underlying reason: infrastructure changes are expensive to get wrong and often hard to reverse, which makes “diagnose and report, let a human decide” the right default scope for a first version of either skill, even though a more capable version could plausibly propose or even apply a fix.

Testing Both Skills

For terraform-plan-review, test against a plan with only additive changes (should read as low-risk), a plan with one buried -/+ on a stateful resource inside many other unrelated changes (the skill needs to surface it, not let it hide in volume), and a plan where the total affected resource count is surprisingly large relative to the stated change. For terraform-drift-detect, this is hardest to test without a real environment that’s actually drifted — if you can safely make a manual change in a sandbox/test environment and confirm the skill catches it, that’s a far more reliable signal than reasoning about the skill’s instructions alone.

Summary

• terraform-plan-review flags destructive changes (- and -/+) hiding inside a plan, especially on stateful resources, and refuses to suggest apply alongside a destructive finding
• terraform-drift-detect surfaces mismatches between Terraform’s state and real infrastructure, and deliberately refuses to auto-resolve which side is correct
• Both skills stay strictly read-only, mirroring the Kubernetes pack’s boundary, for the same reason: infrastructure mistakes are expensive and often hard to reverse
• Test plan-review against a destructive change buried in a large plan specifically — that’s the realistic failure mode, not a plan with only one change to review

Next, cost review and least-privilege checks for AWS — a pack for infrastructure spend and access, not just infrastructure state.