Infrastructure as Code Review

Review Terraform, CloudFormation, or Kubernetes manifests for blast radius, security defaults, state risk, and what the plan will really do.

Infrastructure code to review:
"""
[PASTE THE TERRAFORM, CLOUDFORMATION, PULUMI, OR KUBERNETES MANIFESTS. INCLUDE THE PLAN OUTPUT IF YOU HAVE IT.]
"""

Review the infrastructure code above as the person who will be paged when it breaks.

Environment: [PROD / STAGING / DEV] and what runs on it: [WORKLOAD]
What this change is meant to do: [INTENT]
Blast radius tolerance: [e.g. "zero downtime required" / "a short maintenance window is fine"]

Report findings by severity (blocker, major, minor), each with the resource, the concrete failure it causes, and the smallest fix.

Check specifically for:
- **Destructive changes**: resources this will replace rather than update, and anything that would destroy data. Name the exact resource and what is lost. If plan output is provided, quote the replacement lines. If not, name which changes force replacement for this provider.
- **Blast radius**: what breaks during the change and for how long, what depends on these resources, and whether the change is safe to apply during traffic.
- **Security defaults**: public network exposure, overly broad IAM or RBAC permissions, unencrypted storage or transit, secrets in plaintext or in state, missing network policies, containers running as root, missing resource limits.
- **State and locking**: remote state configuration, locking, whether this change could race with another apply, and anything that would be painful to import or move later.
- **Reliability**: single points of failure, missing health checks or probes, no autoscaling headroom, missing backups or retention, no defined rollback.
- **Drift and reproducibility**: hardcoded values that should be variables, unpinned provider or module versions, resources likely modified by hand outside this code.
- **Cost**: anything that will cost significantly more than the current setup, with the resource named.

Then:
1. The **apply order and rollback plan**: what to apply first, what to verify between steps, and how to roll back each step. Say plainly if any step is not rollbackable.
2. **What I should run before applying** to confirm the review: the exact commands.

If the code looks safe, say so and state what you verified. Only report findings you can tie to a specific line and a specific failure.

How to use

Infrastructure review differs from code review in one way that matters: the failure mode is not a bug, it is a resource being replaced instead of updated, and that difference is invisible in the diff and visible in the plan. Always paste the plan output when you have it. The rollback question is the one to insist on, since 'we will just revert the commit' is not a rollback plan for anything stateful.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.