deploying-infra · diff
git:20260602.5ac56fc to git:20260603.f0f4806
93 added, 157 removed. Audit B to B.
---
description:
- 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.
+ Validate infrastructure changes and, after explicit confirmation, apply Terraform,
+ Helm, Kustomize, or Kubernetes deployments. Use when the user says "deploy",
+ "deploy to staging", "terraform apply", "helm upgrade", "kubectl apply",
+ "rollout", "deploy check", "validate deployment", or "validate infrastructure".
+ Dockerfiles and GitHub Actions are validate-only here. NOT for ongoing service
+ troubleshooting, cloud inspection, rollback investigation, or authoring infra from
+ scratch; use operating-infra for those.
name: deploying-infra
targets:
- claude
---
# Deploy Infrastructure
- ## Usage
-
- ```
- /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.
-
- ## Step 1: Parse Arguments
-
- **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 ID
-
- ## Step 2: Detect Infrastructure Type
-
- Use 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` - Helm
-
- ### If no infrastructure detected
+ Validate first. Apply only after explicit confirmation. Never invent deploy paths,
+ release names, workspaces, namespaces, accounts, or environments.
- Stop: "No infrastructure files found. Looking for: \*.tf, Chart.yaml, kustomization.yaml, k8s/, Dockerfile"
+ ## Scope
- ### If required CLI tools are absent
+ Use for dry-run validation, Terraform/Helm/Kustomize/Kubernetes apply after
+ confirmation, and rollout verification after apply.
- Stop: "Missing tools: {list}. Install before proceeding." Do not attempt commands with unavailable tools.
+ Do not use for live troubleshooting, rollback investigation, cloud inspection,
+ authoring infra, pushing Docker images, triggering GitHub Actions workflows, or
+ applying without plan/diff evidence. Use `operating-infra` for inspection and
+ troubleshooting.
- ## Step 3: Pre-flight Validation
+ Dockerfiles and GitHub Actions are validate-only in this skill.
- Dry-run-before-apply safety doctrine: `operating-infra` `## Boundary`.
+ ## Usage
- Read `references/validation-checklists.md` (skill-relative). Map
- `{detected_type}` to its section header, then copy that section verbatim into
- `{checklist}` below:
+ `/deploying-infra --dry-run [environment] [scope]` validates only. `/deploying-infra --apply <environment> [scope]` validates, asks, applies, then verifies. `/deploying-infra --background --dry-run [environment] [scope]` starts background validation.
- - `k8s` → `## Kubernetes`
- - `helm` → `## Helm`
- - `kustomize` → `## Kustomize`
- - `terraform` → `## Terraform`
- - `docker` → `## Dockerfile`
- - `github-actions` → `## GitHub Actions`
+ Rules:
- The spawned engineer has no skill-relative access, so the checklist must be
- inlined — do not pass a path.
+ - Default mode is `--dry-run`.
+ - `--background` is valid only with `--dry-run`.
+ - `--apply` always stops for confirmation after showing plan/diff evidence.
+ - Production confirmation must include the exact environment name.
+ - If environment, context, namespace, workspace, chart, release, path, or account is unclear, ask one question.
- Spawn the engineer agent for validation:
+ ## Workflow
- ```
- Task(
- subagent_type="engineer",
- run_in_background={true if --background else false},
- description="Pre-flight validation",
- prompt="Validate infrastructure before deployment.
+ 1. Parse mode, environment, and optional scope.
+ 2. Detect infra with `Glob`, `Grep`, and `Read` before shell commands.
+ 3. Classify detected types: apply-capable Terraform/Helm/Kustomize/Kubernetes; validate-only Dockerfile/GitHub Actions.
+ 4. Check required CLIs with safe version or discovery commands.
+ 5. Read `references/validation-checklists.md` and use only detected sections.
+ 6. Run validation and inspect source-backed policy checks.
+ 7. For apply-capable types, show plan/diff evidence.
+ 8. Stop on `--dry-run`; ask and apply on `--apply`.
+ 9. Verify changed resources after apply.
- Type: {detected_type}
- Environment: {environment}
- Mode: {dry-run|apply}
+ Use a background or delegated validation agent only for large scans or explicit
+ `--background`. The agent validates only; it must not apply changes.
- Run these pre-flight checks:
- {checklist}
+ ## Validation and evidence
- Output format:
- READY/BLOCKED per category with file:line for issues.
- Severity: CRITICAL / IMPORTANT / SUGGESTION"
- )
- ```
+ Every validation claim needs exact command output, `file:line`, or a skipped-check
+ reason. For apply-capable types, plan/diff evidence is mandatory before confirmation.
+ Use the reference checklist for commands. Do not run commands with unresolved
+ placeholders; ask first.
- ### If --background
+ Before confirmation, show:
- Return agent ID immediately for later collection.
+ ```markdown
+ ## Pre-flight: READY | BLOCKED
- ## Step 4: Review Changes
+ ### Scope
- ### Present diff/plan to user
+ - Environment: <env>
+ - Type: <terraform|helm|kustomize|kubernetes>
+ - Context/account/namespace/workspace: <value>
- ```
- ## Pre-flight: {READY|BLOCKED}
+ ### Plan or Diff Evidence
- ### Changes Summary
- {terraform plan output / helm diff / kubectl diff}
+ - `<command>` — <summary>
### Resources Affected
- - {resource type}: {count} to create, {count} to modify, {count} to destroy
- ### Warnings
- - {any destructive changes}
- - {any security concerns}
- ```
-
- ### If BLOCKED
-
- Stop and show blockers. Do not proceed to Step 5.
-
- ## Step 5: Research Best Practices (if needed)
+ - Create: <count or unknown>
+ - Modify: <count or unknown>
+ - Delete: <count or unknown>
- For uncertain findings, use Perplexity for current best practices:
+ ### Risks
- ```
- mcp__perplexity-ask__perplexity_ask with:
- "Current best practices for {specific concern} in {technology} 2024-2025"
+ - <destructive changes, security concerns, missing evidence, or none>
```
- ### If --dry-run
-
- Stop here. Output the Step 4 pre-flight summary as the final result.
-
- ## Step 6: Confirm Production Deploys
-
- ### If environment = production
-
- **STOP**: `AskUserQuestion`
-
- - **Production** — Deploy to PRODUCTION? Options: 1. **Yes, deploy** - Apply changes now 2. **Review again** - Show full diff 3. **Cancel** - Abort deployment
+ If validation is blocked, stop. Do not continue to confirmation.
- ## Step 7: Apply Changes
+ ## Confirmation and apply
- ```bash
- # Record deployment start
- echo "$(date -Iseconds) DEPLOY_START env=$environment" >> .deploy.log
+ Ask before every apply with options: apply now, review plan again, cancel. For
+ production, require the exact environment name. Cancel on ambiguous or mismatched
+ confirmation.
- # 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
+ Allowed apply patterns only:
- # Record completion
- echo "$(date -Iseconds) DEPLOY_END status=$?" >> .deploy.log
- ```
+ - `terraform apply tfplan`
+ - `helm upgrade --install <release> <chart> --values <values-file>`
+ - `kustomize build <overlay> | kubectl apply -f -`
+ - `kubectl apply -f <path>`
- ## Step 8: Post-Deploy Verification
+ Use only commands already matched to the repo layout. Do not write deployment logs
+ unless the repo already documents that convention.
- ```bash
- # Wait for rollout
- kubectl rollout status deployment/{name} --timeout=300s
+ If apply fails, stop with `DEPLOYMENT FAILED`. Do not rollback without separate
+ confirmation.
- # Health check
- kubectl get pods -l app={name}
- ```
+ ## Verification
- ### If rollout status times out
+ After apply, verify the changed resources with the relevant checklist command or
+ repo convention. If rollout times out or health is degraded, show investigation
+ and rollback options, then ask what to do next.
- Do not wait further. Show rollback commands and ask: "Rollout is taking longer than expected — rollback or investigate?"
+ ## Output contracts
- ### If rollout fails
+ Use the matching header, then the listed fields.
- ```
- ROLLBACK AVAILABLE
+ ```text
+ DRY RUN COMPLETE
+ Status; Environment; Types; Validation; Plan/Diff; Blockers; Skipped
- kubectl rollout undo deployment/{name}
- # or
- terraform apply -target=... (previous state)
- # or
- helm rollback {release}
- ```
+ AWAITING CONFIRMATION
+ Environment; Type; Command; Destructive changes; Confirmation needed
- ## Output
+ BACKGROUND VALIDATION STARTED
+ Agent ID; Mode; Scope
- ```
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}
+ Environment; Type; Status; Applied; Verification; Rollback option
- Rollback: {command if needed}
+ DEPLOYMENT BLOCKED | DEPLOYMENT FAILED
+ Environment; Type; Reason; Evidence; Next step
```
- Pairs with `operating-infra` for patterns, inspection, and troubleshooting.
+ ## Failure handling
+
+ - Unknown target detail: ask one question.
+ - Missing tool, missing plan/diff evidence, unshown destructive change, or blocked validation: stop.
+ - Apply failure or partial deployment: report exact evidence and ask before rollback.
+ - Rollout timeout or degraded health: show rollback and investigation options, then ask.
+ - User cancels or gives ambiguous confirmation: stop cleanly.