Vibeship-spawner-skills infrastructure-as-code

id: infrastructure-as-code

install

source · Clone the upstream repo

git clone https://github.com/vibeforge1111/vibeship-spawner-skills

manifest: backend/infrastructure-as-code/skill.yaml

GOOD: Focused module

module "vpc" { source = "./modules/networking/vpc"

name        = "production"
cidr_block  = "10.0.0.0/16"
environment = "prod"

}

module "rds" { source = "./modules/database/postgres"

name            = "main"
vpc_id          = module.vpc.vpc_id
subnet_ids      = module.vpc.private_subnet_ids
instance_class  = "db.r5.large"
engine_version  = "15.4"

}

BAD: Monolithic module that does everything

module "infrastructure" { source = "./modules/everything" # 50+ variables, creates VPC, RDS, EC2, S3, IAM... }

name: Provider Version Pinning description: Lock provider versions to prevent unexpected changes when: Always - every terraform configuration example: | terraform { required_version = ">= 1.5.0"

required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = "~> 5.0"  # Allow 5.x patches, not 6.0
  }
  random = {
    source  = "hashicorp/random"
    version = "= 3.5.1"  # Exact version for stability
  }
}

}

Run terraform init -upgrade to update within constraints

Commit .terraform.lock.hcl for reproducible builds

name: Destroy Protection for Critical Resources description: Prevent accidental deletion of stateful or critical resources when: Production databases, storage, or any resource with data that can't be recreated example: | resource "aws_rds_instance" "production" { identifier = "prod-main-db" # ... configuration
```
lifecycle {
  prevent_destroy = true
}
```
}

resource "aws_s3_bucket" "user_uploads" { bucket = "myapp-user-uploads-prod"
```
lifecycle {
  prevent_destroy = true
}
```
}

Note: prevent_destroy doesn't help if you remove the

resource from config entirely - use AWS deletion protection too

resource "aws_rds_instance" "production" { deletion_protection = true # AWS-level protection }
name: Secrets via External Sources description: Never store secrets in Terraform config or state - use secret managers when: Any secret, credential, or sensitive value example: |

GOOD: Reference secrets from AWS Secrets Manager

data "aws_secretsmanager_secret_version" "db_password" { secret_id = "prod/database/password" }

resource "aws_rds_instance" "main" { password = data.aws_secretsmanager_secret_version.db_password.secret_string }

Mark outputs as sensitive

output "db_password" { value = data.aws_secretsmanager_secret_version.db_password.secret_string sensitive = true }

BAD: Hardcoded or variable secrets

variable "db_password" { default = "super-secret-123" # Will be in state file! }

anti_patterns:

name: Local State File description: Storing terraform.tfstate on local filesystem why: State gets lost, multiple engineers overwrite each other, no locking, no backup. One laptop crash and you're manually importing 200 resources. instead: Always use remote backend with encryption and locking (S3+DynamoDB, GCS, Azure Blob, Terraform Cloud).
name: Single Monolithic State description: One state file for all environments and all resources why: Blast radius is entire infrastructure. One mistake, one corrupted state, everything affected. Plan takes 20 minutes to run. instead: Separate state per environment and per logical boundary (networking, compute, data).
name: Secrets in Variables description: Passing secrets via tfvars or environment variables why: Secrets end up in state file unencrypted. State file in S3 means secrets in S3. Audit logs show secret values. instead: Use data sources to fetch from secret managers. Mark variables as sensitive. Never commit tfvars with secrets.
name: Manual Console Changes description: Making changes directly in cloud console instead of Terraform why: State drift. Next terraform apply reverts your manual change. Or worse, creates conflicting resources. Debugging is nightmare. instead: All changes through Terraform. Import existing resources. Use terraform refresh to detect drift.
name: No Provider Pinning description: Not specifying provider versions or using "latest" why: Works today, breaks tomorrow when provider updates. CI/CD fails randomly. Different engineers get different plans. instead: Pin versions in required_providers. Commit .terraform.lock.hcl. Update intentionally with terraform init -upgrade.
name: Over-Scoped IAM for Terraform description: Giving Terraform AdministratorAccess or Action = "*" why: Blast radius is entire AWS account. One misconfiguration, attacker has full access. Compliance audit fails. instead: Least privilege. Separate plan (read-only) and apply (write) credentials. Scope to specific services.

handoffs:

trigger: kubernetes or helm or kubectl to: devops context: User needs container orchestration beyond infrastructure provisioning
trigger: security audit or iam review or compliance to: cybersecurity context: User needs security review of infrastructure configuration
trigger: api or application deployment to: backend context: User is moving from infrastructure to application concerns
trigger: monitoring or alerting or observability to: observability-sre context: User needs to monitor the provisioned infrastructure

Vibeship-spawner-skills infrastructure-as-code

AWS S3 + DynamoDB backend

Create the lock table first

Directory structure (recommended over workspaces)

Each environment has its own state

Mistake in dev cannot affect prod state

GOOD: Focused module

BAD: Monolithic module that does everything

Run terraform init -upgrade to update within constraints

Commit .terraform.lock.hcl for reproducible builds

Note: prevent_destroy doesn't help if you remove the

resource from config entirely - use AWS deletion protection too

GOOD: Reference secrets from AWS Secrets Manager

Mark outputs as sensitive

BAD: Hardcoded or variable secrets