# Terraform Change Safety

> Use when authoring, reviewing, testing, or preparing Terraform and OpenTofu changes, especially plans, modules, state, backends, migrations, CI, and production applies. Produces evidence-based GO, CAUTION, or BLOCKED verdicts without applying by default.

- **Type:** Skill
- **Install:** `agentstack add skill-bryann2k-skills-terraform-change-safety`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [BRYANN2K](https://agentstack.voostack.com/s/bryann2k)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [BRYANN2K](https://github.com/BRYANN2K)
- **Source:** https://github.com/BRYANN2K/skills/tree/main/infrastructure/terraform-change-safety

## Install

```sh
agentstack add skill-bryann2k-skills-terraform-change-safety
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Terraform Change Safety

## Overview

Engineer Terraform/OpenTofu and review changes through one safety model: understand the real execution context, inspect the rendered plan, quantify blast radius, prove rollback, then separate recommendation from authorization.

Never run `apply`, `destroy`, `import`, `taint`, `untaint`, `state mv`, `state rm`, `state push`, backend migration, or workspace deletion unless the user explicitly authorizes that exact mutation after seeing scope, risk, and rollback. A request to write, review, validate, or plan infrastructure is not authorization to change infrastructure.

## When to use

- Create or refactor Terraform/OpenTofu modules and compositions.
- Review HCL, a saved plan, plan JSON, drift, state changes, or a production rollout.
- Design remote state, locking, CI, tests, provider authentication, or migrations.
- Investigate replacements, destroys, unknown values, IAM/network changes, or cost impact.

Do not use for raw cloud-console operations unrelated to IaC. Use `cloud-architecture-review` for system-wide architecture assessments.

## Operating modes

| Mode | Trigger | Default boundary |
|---|---|---|
| **Author** | Create or edit IaC | Write repository files; do not apply |
| **Review** | Inspect code, plan, drift, or PR | Read-only |
| **Execute** | User explicitly requests an approved apply/migration | Only the authorized saved plan or procedure |

State the selected mode before acting. If intent is ambiguous, choose **Review**.

## Workflow

### 1. Establish execution context

Inspect before recommending:

- tool and version (`terraform version` or `tofu version`);
- root modules, child modules, provider constraints, lock file, and test files;
- backend type, workspace/environment mapping, account/subscription/project, and region;
- CI workflow, policy checks, cost checks, and ownership boundaries;
- changed files and relevant Git history.

Do not initialize a backend merely to discover it. Never print backend credentials, state values, environment variables, or provider tokens.

**Complete when:** the report names the tool/version, root under review, target environment, backend/workspace posture, and any unknowns.

### 2. Classify the task and load depth

Load only the relevant reference:

- Plan, drift, or production change → `references/plan-and-risk-review.md`
- State, backend, import, move, or migration → `references/state-and-migration-safety.md`
- New module or substantial refactor → `references/module-engineering.md`

Trace resource addresses through modules. Never infer the meaning of a resource from its display name alone.

### 3. Validate in increasing-cost order

Use the repository's own commands first. Otherwise, when the tool is available:

1. format check: `terraform fmt -check -recursive` or `tofu fmt -check -recursive`;
2. initialize safely for validation, avoiding backend configuration where appropriate;
3. `validate`;
4. static/security/policy tests already configured by the project;
5. native tests or repository test harness;
6. create a saved plan for the confirmed target;
7. inspect machine-readable plan JSON, not only the colorized summary.

Report each check as **passed**, **failed**, **skipped**, or **unavailable**. Never convert “tool missing” into “passed.”

**Complete when:** every applicable check has a status and command/evidence.

### 4. Review the rendered change

Inventory all creates, updates, replacements, destroys, reads, imports, moves, and deferred/unknown values. Pay special attention to:

- identity and access boundaries;
- public exposure, routing, DNS, firewall, and load balancers;
- databases, storage, encryption, backups, retention, and deletion protection;
- state/backend/locking changes;
- immutable attributes causing replacement;
- provider or module upgrades;
- autoscaling, quotas, regional/AZ placement, and estimated recurring cost;
- dependencies not represented in Terraform.

A zero-error plan can still be unsafe. A zero-change plan proves only that the evaluated inputs currently render no difference.

### 5. Assign a verdict

Use the risk model in `references/plan-and-risk-review.md`.

- **GO** — evidence is complete, no blocking risk, verification and rollback are executable.
- **CAUTION** — change may proceed only after listed conditions or approvals.
- **BLOCKED** — destructive/irreversible ambiguity, wrong target, stale plan, missing backup/rollback, failed validation, or unresolved security exposure.

The verdict is advice, not execution authorization.

### 6. Prepare execution without performing it

Produce:

- exact target and saved-plan identity;
- ordered change summary and blast radius;
- prerequisites and approval owners;
- pre-change backup/snapshot or restore proof;
- apply procedure using the reviewed artifact;
- health checks and observation window;
- rollback triggers and commands/procedure;
- communications and maintenance-window needs.

Use `templates/change-review.md` for the output.

### 7. Execute only after explicit authorization

Immediately before an authorized mutation:

1. confirm identity, account/project/subscription, region, workspace, and current branch/commit;
2. confirm the reviewed saved plan is current and has not been regenerated silently;
3. confirm locking and backups;
4. restate destructive/replacement actions;
5. execute only the approved step;
6. capture real output and run post-change verification;
7. stop on an unplanned prompt, target mismatch, plan drift, or health regression.

Never use automatic approval flags unless the user explicitly requested unattended execution and the plan is already reviewed.

## Output contract

Every review returns:

1. **Scope and evidence**
2. **Change inventory**
3. **Risk findings**, ordered by severity
4. **Verdict** — GO / CAUTION / BLOCKED
5. **Conditions before execution**
6. **Verification and rollback**
7. **Validation log** — passed / failed / skipped / unavailable

Label assumptions. Cite file paths, resource addresses, and plan fields rather than relying on generic best practices.

## Common pitfalls

- Reviewing only HCL while ignoring evaluated variables and plan JSON.
- Treating `-/+` replacement as an ordinary update.
- Assuming `sensitive = true` keeps a value out of state.
- Reusing one state across unrelated environments or teams.
- Changing backend configuration and infrastructure in the same unbounded operation.
- Regenerating a plan after approval and applying the new, unreviewed artifact.
- Claiming rollback without proving the previous artifact, state recovery, or data restore path exists.

## Verification checklist

- [ ] Tool, version, root, target, backend, and workspace are known.
- [ ] The reviewed plan corresponds to current code and inputs.
- [ ] All creates, updates, replacements, and destroys are accounted for.
- [ ] IAM, network, data, state, cost, and availability impacts were checked.
- [ ] Validation results are real and status-labeled.
- [ ] Rollback and post-change checks are executable.
- [ ] No mutation occurred without explicit authorization.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [BRYANN2K](https://github.com/BRYANN2K)
- **Source:** [BRYANN2K/skills](https://github.com/BRYANN2K/skills)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-bryann2k-skills-terraform-change-safety
- Seller: https://agentstack.voostack.com/s/bryann2k
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.