plugins/infra-ops/skills-codex/deploying-infra/SKILL.md
Sequential infrastructure deployment — detect infra type (Kubernetes, Terraform, Helm, Kustomize, GitHub Actions, Docker), validate configs, dry-run, show diff, apply only after user confirmation, and verify post-deploy health. Includes safety checks for destructive operations.
npx skillsauth add alexei-led/claude-code-config deploying-infraInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Validate and deploy infrastructure changes safely. Dry-run is the default. Never apply changes, especially destructive ones, without explicit confirmation. Keep going through each step — do not skip validation or the confirmation gate.
Check $ARGUMENTS:
--dry-run (default if nothing specified) — validate and show diff only, stop before applying--apply — validate, show diff, confirm with user, then apply[environment] — target environment name (e.g., staging, production)If no arguments are supplied, treat as --dry-run.
Use Glob to find infrastructure files. Do not guess — look at what is actually present.
**/*.tf — Terraform**/Chart.yaml — Helm chart**/kustomization.yaml — Kustomize.github/workflows/*.yml — GitHub Actions**/Dockerfile*, **/docker-compose*.yml — DockerRead the relevant top-level config files to understand the scope of what will be deployed. If no infrastructure files are found, report it and stop.
Run validation tools for each detected type. Read the output before proceeding — fix any validation errors before continuing.
Terraform:
terraform fmt -check
terraform validate
Helm:
helm lint .
helm template . --debug > /dev/null
Kustomize:
kustomize build overlays/<environment> | kubectl apply --dry-run=client -f -
Kubernetes (raw manifests):
kubectl apply --dry-run=client -f <manifests-dir>/
GitHub Actions:
actionlint .github/workflows/*.yml
Security checks to apply manually by reading the files:
latest image tags in K8s or Dockerfilewrite-all), action versions are pinned to @vX.Y.Z-/+ or destroy) without a noteIf CRITICAL issues are found, report them and stop. Ask the user how to proceed.
Generate a preview of what would change:
Terraform:
terraform plan -out=tfplan
Helm:
helm diff upgrade <release-name> . -f values-<environment>.yaml
Kubernetes / Kustomize:
kubectl diff -f <manifests-dir>/
# or
kustomize build overlays/<environment> | kubectl diff -f -
Present the diff summary. Explicitly call out:
If --dry-run was specified, stop here and deliver the validation report.
Ask the user in plain prose: "Here is what will change: [summary]. Should I apply these changes to [environment]?"
For production environments, make the confirmation explicit: "This will apply to PRODUCTION. Confirm?"
Do not proceed until you have a clear yes. If the user wants to review something first, do that and ask again.
Log the deployment start, then apply:
echo "$(date -Iseconds) DEPLOY_START env=<environment>" >> .deploy.log
Terraform:
terraform apply tfplan
Helm:
helm upgrade --install <release-name> . -f values-<environment>.yaml
Kustomize:
kustomize build overlays/<environment> | kubectl apply -f -
Kubernetes (raw manifests):
kubectl apply -f <manifests-dir>/ --recursive
echo "$(date -Iseconds) DEPLOY_END status=$?" >> .deploy.log
Check that the deployment is healthy:
# Kubernetes rollout
kubectl rollout status deployment/<name> --timeout=300s
kubectl get pods -l app=<name>
# Helm
helm status <release-name>
# Terraform
terraform show | head -50
If the rollout fails or pods are not healthy, provide the rollback command immediately:
# Kubernetes
kubectl rollout undo deployment/<name>
# Helm
helm rollback <release-name>
# Terraform (point to last known-good state)
terraform apply -target=<resource>
DEPLOYMENT COMPLETE
===================
Environment: <env>
Type: <terraform|helm|kustomize|k8s|gha>
Mode: <dry-run|applied>
Changes:
- <resource>: <created|modified|destroyed>
Status: HEALTHY | DEGRADED | FAILED
Rollback: <command if applicable>
For dry-run mode, replace "DEPLOYMENT COMPLETE" with "VALIDATION COMPLETE" and omit the rollback line.
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.