alexei-led/deploying-infra
src/skills/deploying-infra/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add alexei-led/claude-code-config deploying-infraInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 5, 2026, 3:40 AM8.0s3 files scanned
SKILL.md
- name:
- deploying-infra
Deploy Infrastructure
Validate first. Apply only after explicit confirmation. Never invent deploy paths, release names, workspaces, namespaces, accounts, or environments.
Scope
Use for dry-run validation, Terraform/Helm/Kustomize/Kubernetes apply after confirmation, and rollout verification after apply.
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.
Dockerfiles and GitHub Actions are validate-only in this skill.
Usage
/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.
Rules:
- Default mode is
--dry-run. --backgroundis valid only with--dry-run.--applyalways 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.
Workflow
- Parse mode, environment, and optional scope.
- Detect infra with
Glob,Grep, andReadbefore shell commands. - Classify detected types: apply-capable Terraform/Helm/Kustomize/Kubernetes; validate-only Dockerfile/GitHub Actions.
- Check required CLIs with safe version or discovery commands.
- Read
references/validation-checklists.mdand use only detected sections. - Run validation and inspect source-backed policy checks.
- For apply-capable types, show plan/diff evidence.
- Stop on
--dry-run; ask and apply on--apply. - Verify changed resources after apply.
Use a background or delegated validation agent only for large scans or explicit
--background. The agent validates only; it must not apply changes.
Validation and evidence
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.
Before confirmation, show:
## Pre-flight: READY | BLOCKED
### Scope
- Environment: <env>
- Type: <terraform|helm|kustomize|kubernetes>
- Context/account/namespace/workspace: <value>
### Plan or Diff Evidence
- `<command>` — <summary>
### Resources Affected
- Create: <count or unknown>
- Modify: <count or unknown>
- Delete: <count or unknown>
### Risks
- <destructive changes, security concerns, missing evidence, or none>
If validation is blocked, stop. Do not continue to confirmation.
Confirmation and apply
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.
Allowed apply patterns only:
terraform apply tfplanhelm upgrade --install <release> <chart> --values <values-file>kustomize build <overlay> | kubectl apply -f -kubectl apply -f <path>
Use only commands already matched to the repo layout. Do not write deployment logs unless the repo already documents that convention.
If apply fails, stop with DEPLOYMENT FAILED. Do not rollback without separate
confirmation.
Verification
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.
Output contracts
Use the matching header, then the listed fields.
DRY RUN COMPLETE
Status; Environment; Types; Validation; Plan/Diff; Blockers; Skipped
AWAITING CONFIRMATION
Environment; Type; Command; Destructive changes; Confirmation needed
BACKGROUND VALIDATION STARTED
Agent ID; Mode; Scope
DEPLOYMENT COMPLETE
Environment; Type; Status; Applied; Verification; Rollback option
DEPLOYMENT BLOCKED | DEPLOYMENT FAILED
Environment; Type; Reason; Evidence; Next step
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.
Related Skills
alexei-led/writing-shell
tools
VerifiedTrustedCommunity
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, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/spec-flow
tools
VerifiedTrustedCommunity
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.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/operating-infra
testing
VerifiedTrustedCommunity
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
33SKILL.mdUpdated Jun 5, 2026
alexei-led/configuring-git-hygiene
development
VerifiedTrustedCommunity
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).
33SKILL.mdUpdated Jun 5, 2026