Infra-as-Code Reviewer

An infrastructure diff can look like three changed lines and behave like an outage. This skill reviews infrastructure-as-code changes — declarative resources, modules, environment configs — with the operator's question first: what will actually happen when this applies, in what order, and what is the worst credible result? It reads the plan, not just the diff, and it prices every change in blast radius before it says a word about style.

When to use this skill

• Reviewing any change to declarative infrastructure definitions or their shared modules
• A change touches state-bearing resources: databases, volumes, queues, DNS, identity policies
• Environment promotion diffs ("mirror staging into production") that are larger than they look
• Post-incident review of the infrastructure change that shipped the incident

Workflow

1. Demand the rendered plan, not just the source diff. What the tooling will create, modify, or destroy is the ground truth. Review the diff for intent and the plan for consequence — a mismatch between the two is itself a finding.
2. Triage destructive actions first. Anything the plan destroys or replaces gets interrogated: is the replacement expected (an immutable field changed) or accidental (a rename the tooling reads as delete-and-create)? For state-bearing resources, a replace is a data-loss event until proven otherwise.
3. Check identity and access changes with least-privilege eyes. New or widened permissions: scoped to the specific resources and actions needed, or wildcarded for convenience? Any principal gaining the ability to escalate its own privileges is a blocking finding regardless of intent.
4. Trace network exposure. New ingress rules, listener configs, public addresses, relaxed firewall rules: what becomes reachable, from where, and does the change description say so out loud?
5. Audit secrets and configuration hygiene: credentials inline in config, secrets landing in state files unencrypted, environment-specific values hardcoded into shared modules.
6. Evaluate reversibility. For each risky change: does rollback mean re-applying the previous definition, or manual surgery (data restore, DNS propagation, certificate reissue)? Irreversible-in-practice changes need a stated fallback before approval.
7. Deliver a verdict with severity-ranked findings, each naming the resource, the consequence at apply time, and the safer alternative. Approve only when destructive surprises are zero and every remaining risk is named and accepted by the author.

Output format

Verdict: approve | request changes
Plan summary: <creates/modifies/destroys counts, destroys itemized>
[BLOCKER] <resource> — <what happens on apply> — <safer alternative>
[RISK]    <resource> — <assumption that must hold> — <how to verify before apply>
[NIT]     <naming, structure, duplication>
Rollback: <re-apply previous | manual steps — spelled out>

Guardrails

• Never approve a change whose plan you have not seen rendered against the target environment; "it planned clean in staging" is evidence about staging.
• Replacement of a state-bearing resource requires a stated data plan: migration, snapshot, or an explicit "empty by design".
• Wildcards in identity policies, network rules, or resource selectors are findings by default; the author owns the argument for keeping each one.
• Module version bumps get the same scrutiny as inline changes — a minor bump can rewrite defaults. Read the module's changelog or diff its source.
• Drift discovered during review (live infrastructure differs from code) halts the review; reconcile first, because a plan against a drifted baseline is a plan against fiction.