- Home
- Skills
- Ancoleman
- Ai Design Components
- Writing Infrastructure Code
writing-infrastructure-code_skill
- Python
291
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill ancoleman/ai-design-components --skill writing-infrastructure-code- outputs.yaml9.8 KB
- SKILL.md15.2 KB
Overview
This skill helps teams provision and manage cloud infrastructure using Infrastructure as Code (IaC) across Terraform/OpenTofu, Pulumi, and AWS CDK. It emphasizes tool selection, state management, reusable module design, and operational patterns to make infrastructure reproducible, auditable, and testable. Use it to establish safe, team-friendly deployment workflows and reduce manual configuration drift.
How this skill works
I inspect your cloud requirements, team composition, and operational constraints to recommend a tool and architecture (declarative vs imperative, remote state backend, module boundaries). I provide concrete artifacts: module layouts, backend configuration, CI/CD plan/apply pipelines, and drift detection routines. I also surface commands, scripts, and checklist items to enforce state locking, encryption, and versioned releases.
When to use it
- Provisioning cloud resources (compute, networking, databases, storage)
- Migrating manual setups into code-based workflows
- Designing reusable, versioned infrastructure modules
- Implementing multi-cloud or hybrid-cloud deployments
- Setting up remote state, locking, and drift detection
- Integrating IaC into CI/CD and release workflows
Best practices
- Choose Terraform/OpenTofu for ops-led multi-cloud, Pulumi for developer-centric logic, AWS CDK when AWS-native integration is primary
- Always use remote state with locking, enable encryption and versioning, and never commit state files to Git
- Start monolithic during exploration then extract modules when a pattern repeats 3+ times; pin provider and module versions for prod
- Document inputs, outputs, and examples for each module; include tests and a changelog before releasing
- Run security scans (Checkov/tfsec), cost estimates (Infracost), and automated plan previews in CI before apply
- Schedule regular drift detection, maintain backups of state, and keep runbooks for recovery
Example use cases
- Create a Terraform VPC module with multi-AZ subnets and NAT gateways
- Set up S3 + DynamoDB remote state backend with locking and versioning for AWS teams
- Build a Pulumi TypeScript component that encapsulates ECS service, ALB, and autoscaling logic with unit tests
- Design layered state isolation: separate networking, compute, and data states to reduce blast radius
- Implement a CI pipeline that runs plan/preview, security scans, cost checks, and gated apply
FAQ
If you need multi-cloud and ops familiarity choose Terraform/OpenTofu; if developers want language ergonomics choose Pulumi; for AWS-only work choose AWS CDK.
How should we structure state for multiple environments?
Prefer directory separation with isolated state per environment for most teams; use workspaces only with strict controls and clear namespacing.