Skip to content
Back to skills

Infrastructure

ASecurity

Terraform, Kubernetes, and Helm conventions. Use when editing infrastructure modules, manifests, charts, or deployment config.

  • 8 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsgokubernetesterraformdatabasebackenddocumentation

Security analysis

A100/100

Scanned September 3, 2026

npx -y skills add edjchapman/claude-code-config --skill infrastructure --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Infrastructure?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Infrastructure
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/edjchapman-infrastructure/badge)](https://www.skillsdirectory.com/skills/edjchapman-infrastructure)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: infrastructure
description: Terraform, Kubernetes, and Helm conventions. Use when editing infrastructure modules, manifests, charts, or deployment config.
---

# Infrastructure Patterns

## Terraform

### Module Structure

- Use a standard layout: `main.tf`, `variables.tf`, `outputs.tf`, `versions.tf`
- Extract reusable patterns into modules under `modules/`
- Keep modules focused -- one resource group per module
- Use `terraform-docs` to auto-generate module documentation

### State Management

- Always use remote state (S3, GCS, or Terraform Cloud)
- Enable state locking (DynamoDB for S3 backend)
- Use separate state files per environment
- Never commit `.tfstate` files to version control
- Use `terraform import` for existing resources, never recreate

### Best Practices

- Pin provider versions in `versions.tf`
- Use `terraform fmt` and `terraform validate` in CI
- Run `terraform plan` in CI, apply only from CD pipeline
- Tag all resources with `environment`, `team`, and `managed_by`
- Use `data` sources to reference existing infrastructure
- Use `locals` for computed values, `variables` for inputs

## Kubernetes

### Resource Limits

- Always set `requests` and `limits` for CPU and memory
- `requests` = guaranteed minimum, `limits` = hard ceiling
- Start conservative and tune based on metrics
- Use `LimitRange` and `ResourceQuota` for namespace defaults

### Probes

- `livenessProbe`: restart if unhealthy (checks process is alive)
- `readinessProbe`: remove from service if not ready (checks dependencies)
- `startupProbe`: allow slow-starting containers before liveness kicks in
- Use HTTP probes for web services, TCP for databases, exec for custom checks
- Set `initialDelaySeconds` based on actual startup time

### Best Practices

- Use `Deployment` for stateless, `StatefulSet` for stateful workloads
- Define `PodDisruptionBudget` for high-availability services
- Use `ConfigMap` for config, `Secret` for sensitive data
- Set `imagePullPolicy: IfNotPresent` and use specific image tags
- Use namespaces to isolate environments and teams

## Helm

### Chart Best Practices

- Use `values.yaml` for defaults, override per environment
- Template helpers go in `_helpers.tpl`
- Include `NOTES.txt` for post-install instructions
- Use `helm lint` and `helm template` in CI
- Pin chart versions in `Chart.lock`
- Use subcharts for shared infrastructure (databases, caches)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…