A plan-review prompt should parse each proposed resource action into create, in-place update, replacement, destroy, import, or state-only change, then compare it with the approved envelope. Replacement is not merely a larger update; it may interrupt service or lose data even when the final name stays the same. Ask which attribute causes replacement and whether it is tied to the requested change. Unknown or sensitive plan fields remain unknown; do not guess at them from a provider's normal behavior. A speculative plan is useful evidence, but the final apply must use a fresh approved plan or a saved reviewed plan under the team's workflow.
Infrastructure plans: classify every action before apply
Operational case
Aster's sanitized plan shows the expected queue-retention update and an unexpected production database replacement. The prompt lists both actions and blocks approval. It asks the operator to inspect the database change's cause and compare current configuration, provider version, and recent drift before any apply. The team later fixes the unintended attribute and regenerates a plan with only the queue update. The old blocked plan is kept in the review record, but it is not used for execution. A fluent summary saying 'minor retention change' would be false while the replacement remains in the plan.
Plan P1: queue retention update -> expected candidate.
Plan P1: database replacement -> BLOCK; cause unresolved.
Investigate configuration, provider, and drift; do not apply P1.
Plan P2: queue update only -> eligible for owner review.
Apply only the exact reviewed plan under the approved workflow.Performance and operating cost
Classifying A plan actions is O(A) inspection before deeper dependency review. A single unexpected replacement can dominate risk, so average action counts are not enough; check every destructive or state-changing action individually. Replanning adds time and provider calls but prevents an obsolete plan from being treated as current evidence. A saved plan file can contain sensitive material and must be handled as a controlled artifact, not attached to public documentation or pasted into an unrestricted prompt.
Common Mistakes
- Do not summarize a plan by its requested change while hiding extra actions.
- Do not treat replacement as an in-place update.
- Do not approve a new plan merely because an earlier plan was reviewed.
Connected lessons
- Prompt engineering applications
- Prompt Engineering
- Generated output: validate again at the destination boundary
- Tool effects: reconcile receipts before retrying
- Terraform replacement: prove old and new can coexist
- Infrastructure prompts: bind scope, owner, and environment
- Infrastructure prompts: quarantine state secrets and drift
- Infrastructure apply: separate review from execution
- Infrastructure release: verify live state and rollback limits
- Project: review an Aster queue retention change
- Infrastructure-change prompt decisions
