iac-change-execution

IaC Change Execution

Given a description of a desired infrastructure change, research the current state, plan the IaC code changes, get operator approval, execute via PR or direct apply, and verify the result — producing a full audit trail.

The Iron Law

NO CODE CHANGES WITHOUT OPERATOR APPROVAL.
NO APPLY WITHOUT PRE-FLIGHT CLEARANCE.
NO LIVE QUERIES OR MUTATIONS WITHOUT EXPLICIT OPT-IN.

Constraints (Non-Negotiable)

1. Operator approves every code change. The skill never commits, pushes, or applies code the operator hasn't reviewed. Show the diff, get approval, then proceed.
2. Pre-flight clearance before every apply. No apply (direct or via PR) without a pre-flight verdict. Reuse a recent record if it covers the same change; invoke pre-flight inline otherwise.
3. No live queries or mutations without opt-in. Research gap-filling queries (Step 1) and health checks (Step 5) require explicit approval. Apply commands (Step 4) require per-command approval.
4. Follow the repo's conventions. Code the skill writes must match existing patterns — naming, module structure, formatting, variable style. The repo is the style guide, not your training data.
5. One phase at a time. Multi-phase changes execute sequentially with a gate between each. Never start Phase N+1 before Phase N's success criteria are confirmed.
6. PR is the default execution path. Direct apply requires the operator to explicitly request it and triggers elevated pre-flight risk scoring.
7. All output goes to .culiops/iac-change-execution/. Execution records are written to .culiops/iac-change-execution/<service>-<action>-<YYYYMMDD-HHmm>.md in the target repo, following the culiops output convention.
8. No rollback automation. The skill documents rollback paths in the plan (informational). Actual rollback is the operator's responsibility.

Rationalization Prevention

Thought	Reality
"This is a trivial change, I can skip pre-flight"	STOP — every apply gets pre-flight. Trivial changes have caused major outages.
"The code style doesn't matter, it works"	STOP — inconsistent style signals the change was not written by the team. Follow the repo's patterns.
"I'll apply all phases at once, they're independent"	STOP — phases are ordered for a reason. Gate between each.
"The operator approved the plan, so I don't need to show the code"	STOP — plan approval and code approval are separate gates. The code might not match the plan.
"Direct apply is faster, I'll default to it"	STOP — PR path is the default. Direct apply is the escape hatch with elevated risk.
"The catalog is stale, I'll just use my knowledge of this cloud service"	STOP — if the catalog is stale, fill gaps with approved live queries. Don't invent state.
"I can chain these apply commands together"	STOP — one command at a time, each shown and approved before execution.
"The plan showed no issues, health checks aren't needed"	STOP — plan success does not equal runtime success. Offer health checks.
"This phase failed but the next phase might fix it"	STOP — stop on failure. Don't proceed to the next phase hoping it resolves the problem.
"The old Terraform state was retired, so this import is safe"	Verify the current owner, not the retired one. A resource can be retired from TF yet actively owned by CloudFormation / Serverless — import that and a stack deploy reverts you.