Review a Terraform plan before applying

When to use this template

• You have run terraform plan and the output is long or dense, and you want a readable account of what will actually change before you apply it.
• A plan touches production, and you want a second look at replacements, deletions and access changes before you approve it.
• Before you start, run the plan yourself and paste its output into the prompt; Claude Code can also read the configuration if the repository is open.

When not to use it

• You have not run a plan yet. Generate the output first; Claude cannot judge a change it cannot see.
• The plan output contains secrets or customer data you are not allowed to share with an AI tool. Redact those values first, or follow your team's policy.
• You want Claude to run the apply. Keep apply as a step you take yourself after reading the review; this template only reads.

Why this structure

• The plan goes first inside <plan> tags, and the prompt says to treat it as data. Plan output contains resource names and values that could include stray text, and the tags keep it apart from your instructions.
• The environment choice changes how much weight Claude gives to downtime and data loss, which matter far more in production than in a test environment.
• The optional intent line lets Claude flag changes your intent does not explain, which is often how unexpected drift or a wrong variable shows up.
• The rule against apply and state-changing commands tells Claude not to turn the review into a live change. You decide when to apply.
• The truncation rule makes Claude say what it could not judge, such as values only known after apply, instead of filling the gap with a guess.
• The report starts with a plain summary and ends with a clear recommendation, so a reviewer can read the first and last parts and know where to look in between.

Example input (fictional)

Terraform plan output

Terraform will perform the following actions:

  # aws_instance.worker[3] will be created
  + resource "aws_instance" "worker" {
      + instance_type = "t3.medium"
    }

  # aws_db_instance.main must be replaced
-/+ resource "aws_db_instance" "main" {
      ~ engine_version = "14.9" -> "15.4" # forces replacement
    }

Plan: 2 to add, 0 to change, 1 to destroy.

Target environment

production, where downtime or data loss affects real users

What the change is meant to do

Increase the worker pool from 3 to 5 instances and nothing else

Follow-ups to send Claude

• For the replaced database, explain what happens to its data during the replacement and list ways to avoid the replacement.
• Write the plan summary as a short change request note for my team: what changes, the risk, and the rollback steps.
• Read the Terraform files in this repository and point to the exact lines that cause each change in the plan.

Common mistakes

• Pasting only the final count line. The resource details above it carry the information that matters, such as which change forces a replacement.
• Skipping the intent. Without it Claude can describe the plan but cannot tell you which changes you did not mean to make.
• Treating the review as approval. Read the risks yourself, and check anything marked as unknown before you apply.

Related templates

• Review a pull request: Give Claude Code a pull request number; it reads the diff and the code around it, summarizes what changed and lists concerns, without posting anything.
• Investigate a production incident: Give Claude Code the symptom and when it started; it checks logs, recent deploys and config changes, then names the most likely cause with evidence.
• Code review prompt: Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.

See all templates

Sources

• Claude Code docs: Prompt library (Anthropic documentation)
• Claude Code best practices: Provide rich content (Anthropic documentation)
• Prompting best practices: Structure prompts with XML tags (Anthropic documentation)