plugins/infra-ops/skills/deploying-infra/SKILL.md
Validate and deploy Kubernetes, Terraform, Helm, Kustomize, GitHub Actions, and Docker configs. Use when user says "deploy", "deploy to staging", "apply changes", "terraform apply", "helm upgrade", "kubectl apply", "rollout", "deploy check", "validate deployment", "validate infrastructure", or wants to verify or apply infrastructure changes.
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 changes to Kubernetes, Terraform, Helm, or Kustomize with pre-flight checks, security validation, and rollback support.
/deploying-infra --dry-run # Validate only (default)
/deploying-infra --apply staging # Apply to staging
/deploying-infra --apply production # Apply to production (requires confirmation)
--dry-run runs steps 1–5 (validation only). --apply runs all 8 steps.
Default: --dry-run (safe mode)
--dry-run → Validate without applying (stops after step 5)--apply → Apply changes after validation[environment] → Target environment (staging, production, dev)--background → Run validation in background, return agent IDUse Glob to find infrastructure files (quick scan):
**/*.yaml, **/*.yml - K8s, Helm, Kustomize.github/workflows/*.yml - GitHub Actions**/*.tf - Terraform**/Dockerfile*, **/docker-compose*.yml - Docker**/kustomization.yaml - Kustomize**/Chart.yaml - HelmIf no infrastructure detected: "No infrastructure files found. Looking for: *.tf, Chart.yaml, kustomization.yaml, k8s/, Dockerfile"
Spawn infra-engineer for validation:
Task(
subagent_type="infra-engineer",
run_in_background={true if --background else false},
description="Pre-flight validation",
prompt="Validate infrastructure before deployment.
Type: {detected_type}
Environment: {environment}
Mode: {dry-run|apply}
Run pre-flight checks:
**Kubernetes:**
- kubectl apply --dry-run=client -f <files>
- Check: security contexts, resource limits, non-root users
- Check: liveness/readiness probes defined
- Check: no 'latest' image tags
- Check: namespace exists or will be created
- Check: secrets/configmaps referenced exist
**Helm:**
- helm lint <chart>
- helm template --debug
- helm diff upgrade (if helm-diff installed)
- Check: values.yaml has sensible defaults
**Kustomize:**
- kustomize build | kubectl apply --dry-run=client -f -
- Validate overlays for {environment}
**GitHub Actions:**
- actionlint (if available)
- Check: secrets not hardcoded
- Check: permissions minimized (not 'write-all')
- Check: pinned action versions (@vX.Y.Z not @main)
**Terraform:**
- terraform fmt -check
- terraform validate
- terraform plan -out=tfplan
- Check: no hardcoded credentials
- Check: state backend configured
- Check: no destructive changes without confirmation
- Check: state lock acquired
**Dockerfile:**
- Multi-stage builds where appropriate
- Non-root user (USER directive)
- Pinned base image tags (not :latest)
- No secrets in build args
Output format:
READY/BLOCKED per category with file:line for issues.
Severity: CRITICAL / IMPORTANT / SUGGESTION"
)
If --background: Return agent ID immediately for later collection.
Present diff/plan to user:
## Pre-flight: {READY|BLOCKED}
### Changes Summary
{terraform plan output / helm diff / kubectl diff}
### Resources Affected
- {resource type}: {count} to create, {count} to modify, {count} to destroy
### Warnings
- {any destructive changes}
- {any security concerns}
If BLOCKED: Stop, show blockers.
For uncertain findings, use Perplexity for current best practices:
mcp__perplexity-ask__perplexity_ask with:
"Current best practices for {specific concern} in {technology} 2024-2025"
If --dry-run: Stop here with validation summary.
If environment = production:
STOP: AskUserQuestion
| Header | Question | Options | | ---------- | --------------------- | ------------------------------------------------------------------------------------------------------------------ | | Production | Deploy to PRODUCTION? | 1. Yes, deploy - Apply changes now<br>2. Review again - Show full diff<br>3. Cancel - Abort deployment |
# Record deployment start
echo "$(date -Iseconds) DEPLOY_START env=$environment" >> .deploy.log
# Apply based on type
case $type in
terraform)
terraform apply tfplan
;;
helm)
helm upgrade --install {release} {chart} -f values-{env}.yaml
;;
kustomize)
kustomize build overlays/{env} | kubectl apply -f -
;;
k8s)
kubectl apply -f k8s/{env}/ --recursive
;;
esac
# Record completion
echo "$(date -Iseconds) DEPLOY_END status=$?" >> .deploy.log
# Wait for rollout
kubectl rollout status deployment/{name} --timeout=300s
# Health check
kubectl get pods -l app={name}
If rollout fails:
ROLLBACK AVAILABLE
kubectl rollout undo deployment/{name}
# or
terraform apply -target=... (previous state)
# or
helm rollback {release}
DEPLOYMENT COMPLETE
===================
Environment: {env}
Type: {terraform|helm|kustomize|k8s}
Duration: {time}
Agent ID: {id} (use /agent:resume {id} to continue)
Applied:
- {resource}: {action}
Status: {HEALTHY|DEGRADED|FAILED}
Rollback: {command if needed}
Pairs with managing-infra skill for patterns and reference material.
Execute deployment workflow now.
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.