Infrastructure as code

Skill vignesh2027/AI-AGENT-SKILLS/skills/infrastructure-as-code

Turn your ai agent into senior engineer..The result is fast code that fails slowly. AI Agent Skills solves this by giving agents the same disciplined workflows senior engineers use

Install

npx -y skills add vignesh2027/AI-AGENT-SKILLS --skill infrastructure-as-code

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Manage infrastructure with version-controlled, reviewed, and tested IaC

SKILL.md

2.9 KB, as published. Nobody here has run it

Overview

Infrastructure defined by hand is infrastructure that drifts, that can't be reviewed, and that can't be reproduced. This skill enforces that all infrastructure is version-controlled code with the same discipline as application code: specs, reviews, tests, and staged deployment.

When to Use

Before provisioning any cloud resource
Before modifying production infrastructure
When investigating a drift between expected and actual infrastructure state

Process

Step 1: Define the desired state first

Write the IaC code that represents the desired state before applying it. Terraform plan / Pulumi preview / CloudFormation change set must be reviewed before apply.

Step 2: Review the plan output

The plan is the diff for infrastructure changes. Review it as carefully as a code diff:

Are only expected resources being created/modified/destroyed?
Are any resources being replaced (destroy + create) that should only be modified?
Are sensitive values being exposed in the plan output?

Step 3: Blast radius analysis

Before applying:

What is the maximum impact if this change fails?
Does this change affect production traffic?
Does this change touch the database, auth system, or network layer?
Is the rollback procedure documented?

High blast radius changes require explicit approval from a second engineer.

Step 4: State management

Use remote state with locking (never local state for team environments)
Never manually modify state files
Version state file changes
Test: can you destroy and recreate from scratch?

Step 5: Drift detection

Run drift detection on a schedule. If the actual state diverges from the IaC state, investigate and resolve — don't let drift accumulate.

Step 6: Secrets management

No secrets in IaC code or state files
Use: Vault, AWS Secrets Manager, GCP Secret Manager, or similar
Rotate secrets via IaC, not manually

Step 7: Test the IaC

Unit tests for modules (Terratest, Pulumi testing)
Integration tests: deploy to a non-prod environment and verify
Destroy test: can you tear it down and recreate it?

Step 8: Staged apply

Apply to: development → staging → production. Wait for validation at each stage before proceeding.

Anti-Rationalizations

"It's a small change — I'll do it in the console" Console changes become invisible drift. IaC is the only source of truth. No exceptions.

"We don't need to test infrastructure" Untested IaC fails at the worst moment: during an incident when you need to provision fast.