SkillVaultskills Browse all 500 skills

Infrastructure · Version 1.7.0 · Reviewed 2026-08-02

Terraform Reviewer

Review and harden plan risk review and module design with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Finds destructive changes, state risks, privilege issues, unstable addressing, and unsafe infrastructure defaults.

₹99 one-time

Get this skill archive

What this skill helps you do

  • Plan risk review
  • Module design
  • State migration guidance

How Terraform Reviewer works

You provide

The plan output, module layout, and provider versions

It inspects

Every forces-replacement line and address-stability change

It decides

Approve, block, or resequence with a rollback path

You verify

JSON plan diff showing zero unexpected replacements

What it checks first

Terraform Reviewer finds destructive changes, state risks, privilege issues, unstable addressing, and unsafe infrastructure defaults. Use it when the work involves Plan risk review, Module design, State migration guidance.

  1. Every `# forces replacement` line in the plan, and whether the resource holds state that cannot be recreated.
  2. Resource address stability: `count` on a list makes removal of a middle element re-index and destroy unrelated resources.
  3. The order of create-versus-destroy for replacements, since the default destroys before creating for non-`create_before_destroy` resources.
  4. Whether the plan contains changes nobody requested, which indicates drift or a provider default change.
  5. Secrets in state: any value marked sensitive is still stored in plaintext in the state file.

Failure modes it recognizes

  • An immutable attribute change (subnet group, availability zone, engine version class) silently forcing database replacement and data loss.
  • Moving a resource between modules without `moved` blocks, so Terraform destroys and recreates it.
  • A `for_each` converted from `count` re-creating every resource because the addresses changed.
  • Provider version drift introducing new defaults that appear as unrequested plan changes.
  • State lock left held by a crashed run, blocking all subsequent applies.
  • A data source that resolves at plan time to a value that changes by apply time, producing an inconsistent result.

Answers it will reject

  • Approving a plan by reading the summary counts instead of the replacement lines — the counts hide data loss.
  • Using `-target` to work around a broken dependency graph, which leaves state partially applied and inconsistent.
  • Committing `terraform.tfstate` to version control, exposing secrets and creating merge conflicts on infrastructure.
  • Adding `lifecycle { ignore_changes = all }` to silence drift, which permanently disables reconciliation.

Decision rules it applies

  • Any replacement of a stateful resource requires an explicit backup and restore plan before approval.
  • Prefer `moved` blocks over destroy-and-recreate for refactors; they are free and preserve state.
  • Pin provider versions with `~>` and upgrade deliberately, so plan noise is attributable to intent.
  • If the plan cannot be explained line by line, do not apply it — an unexplained diff is an unreviewed change.

Evidence it asks for

  • `terraform plan -out=tfplan` then `terraform show -json tfplan` to inspect changes programmatically.
  • Grep the JSON plan for `"replace"` actions and cross-check each against a stateful-resource inventory.
  • `terraform state list` to confirm addresses before and after a refactor.

The method inside

  1. Map the artifact, actors, boundaries, and invariants relevant to plan risk review.
  2. Trace concrete failure or abuse paths for module design; do not report checklist items without a mechanism.
  3. Prioritize state migration guidance findings by impact, likelihood, confidence, and cost of correction.
  4. Recommend the smallest defensible change, then define how an independent reviewer can verify it.

Deliverables

  • Plan risk review assessment
  • Module design decision and action plan
  • State migration guidance verification checklist

Evidence requirements

  • Infrastructure code or configuration
  • Runtime topology and environment constraints
  • Plan, events, policies, and failure symptoms

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Review this Terraform plan before production apply. Focus on replacement, identity, and data-loss risk.

Expected output

The database replacement is caused by an immutable subnet-group change. Applying now will destroy the current instance before the replacement is healthy...

Boundaries and compatibility

Ideal for

  • Plan risk review: produce a decision or artifact grounded in supplied evidence.
  • Module design: produce a decision or artifact grounded in supplied evidence.
  • State migration guidance: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Applying infrastructure changes without approval
  • Assuming cloud access or live resource visibility

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.