terraform-blast-radiuslisted

Review a Terraform or OpenTofu plan for destructive changes before you apply — the resources that will be destroyed and recreated (downtime), the stateful ones whose replacement means data loss, renames and count shifts that trigger mass recreation, and changes to shared resources with a wide blast radius. Explains which attribute forces replacement and rewrites the change to be safe with lifecycle rules, moved/removed blocks, for_each, or an out-of-band migration. Use whenever writing, reviewing, or about to apply Terraform/OpenTofu — reading a `terraform plan`, changing a resource attribute, renaming or removing a resource, upgrading a provider, or touching a database, disk, bucket, or other resource that holds data.
windchillscalanthes-ship-it/terraform-blast-radius · ★ 0 · DevOps & Infrastructure · score 73

Install: claude install-skill windchillscalanthes-ship-it/terraform-blast-radius

# Terraform Blast-Radius Review Catch the infrastructure change that quietly destroys and recreates a resource — and turn it into a safe apply before it takes production down or deletes your data. A single innocent-looking edit (a renamed resource, a changed `name`, a new `engine_version`, removing one element from a `count` list) can make Terraform plan a **destroy-and-recreate** instead of an in-place update. On a stateless resource that's a downtime window while it's gone; on a **stateful** one — a database, a disk, a bucket — it's irreversible **data loss**. It passes review because the diff looks small, and then `apply` prints `Destroy: 1` and it's too late. This skill reads the plan, explains exactly *what* will be replaced and *why*, and produces a safe rewrite. ## When to use this - You are **writing** Terraform/OpenTofu and want a change checked before commit. - You are **reviewing** a `.tf` diff or a `terraform plan` in a PR. - You are about to **apply** — especially if the plan shows any replace or destroy. - Someone asks "will this destroy the database?", "why is it recreating this?", or "how do I change this without downtime?". If the resource is stateless, throwaway, or in a dev sandbox, a recreate may be completely fine — say so and don't over-engineer. The question is always **what gets destroyed, and does it hold data or serve traffic.** ## Workflow 1. **Establish context.** Identify the **provider(s) and versions** (`aws`, `google`, `azurerm`, …)