writing-infrastructure-code_skill

This skill helps you design and manage cloud infrastructure with IaC tools, enabling reusable modules, safe state handling, and scalable deployment workflows.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
writing-infrastructure-code skill by ancoleman/ai-design-components | VeilStrat