agentsclimarketplace

Deploying infra

Skill alexei-led/cc-thingz/src/skills/deploying-infra

Portable skills, agents, hooks, and Pi extensions for Claude Code, Codex CLI, Copilot, Cursor, Grok, and Pi.

Install
npx -y skills add alexei-led/cc-thingz --skill deploying-infra

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

5.0 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

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.
  • --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.

Workflow

  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.

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 tfplan
  • helm 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.

What ships with it: 2 files

4.3 KB alongside SKILL.md

.agentbundler/

references/

Gives 0 of the 12 instructions most containers cloud skills give in ~1.0k tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildsin 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • default to dry-run validation mode
  • ask one clarifying question for unclear targets
  • detect infrastructure type before running shell commands
  • check required CLIs before validating
  • run validation against detected infrastructure
  • show plan or diff evidence before confirmation

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.