Agent skill

Atmos Kubernetes

by cloudposse in cloudposse/atmos

Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers…

Apache-2.0Auto-check passedDevOps & Cloud

Install Atmos Kubernetes

skills CLI
$ npx skills add cloudposse/atmos --skill atmos-kubernetes -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install cloudposse/atmos atmos-kubernetes --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/cloudposse/atmos.git skills-src && mkdir -p .claude/skills && cp -r skills-src/agent-skills/skills/atmos-kubernetes .claude/skills/atmos-kubernetes && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
atmos-kubernetes
GitHub stars
1.4k
Token cost
~2.8k tokens
SKILL.md length
928 words
Files
1
Skills in repo
70
Repo updated
First seen
Licence
Apache-2.0

At a glance

Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers…

  • Tasks that involve Container orchestration
  • SKILL.md covers Related Skills, Component Shape, Commands and Provision Targets (GitOps…, plus 5 more sections
  • Calls kubectl; reaches github.com

What it does

Atmos Kubernetes is an agent skill from cloudposse/atmos. Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers, paths/manifests, provision targets (cluster vs. GitOps repo), and auth

Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in DevOps & Cloud, covering Container orchestration. It works with Kubernetes and Git. The repository describes itself as: Atmos is the open-source runtime for infrastructure — it builds, authenticates, and ships Terraform, OpenTofu, Packer, Ansible, Kubernetes, Helm, and containers the same way on… The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Container orchestration

Example prompts

  • “/atmos-kubernetes”

What it can do on your machine

Read from SKILL.md and the folder at commit 36726ae. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • kubectl

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Atmos Kubernetes loads about 2.8k tokens when it runs. Until then it costs about 68 tokens; SKILL.md has 928 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~68
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from cloudposse/atmos at commit 36726ae, republished under its Apache-2.0 licence (© cloudposse). 928 words, ~2,754 tokens.

Download SKILL.mdSave it as .claude/skills/atmos-kubernetes/SKILL.md (or your agent's skills folder).
name
atmos-kubernetes
description
Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers, paths/manifests, provision targets (cluster vs. GitOps repo), and auth
metadata.copyright
Copyright Cloud Posse, LLC 2026
metadata.version
1.0.0
metadata.category
orchestrators

Atmos Native Kubernetes Components

Use this skill for the native Kubernetes component type (components.kubernetes). It manages plain YAML/JSON manifests and Kustomize overlays through the Kubernetes Go SDK with server-side apply. No kubectl or kustomize binary is required. This is distinct from Helm chart deployment — see atmos-helm for charts, or atmos-helmfile for Helmfile-based releases.

This feature is experimental. kubectl/kustomize names describe manifest-processing behavior, not the CLI binaries.

NeedLoad
Helm charts (native, Helm Go SDK)atmos-helm
Helmfile-based Kubernetes deploymentsatmos-helmfile
Component dependency ordering for --all/--affectedatmos-components
GitOps delivery targets (provision.targets, kind: git)atmos-git
EKS kubeconfig / cluster authenticationatmos-aws-eks, atmos-auth
Lifecycle hooks around component operationsatmos-hooks
Native CI job summariesatmos-ci
Local Kubernetes emulator (k3s)atmos-emulator

Component Shape

Define Kubernetes objects under components.kubernetes in stack manifests:

yaml
components:
  kubernetes:
    argocd:
      provider: kustomize
      paths:
        - overlays/{{ .vars.cluster }}
      vars:
        namespace: argocd
        cluster: dev
      env:
        KUBECONFIG: /tmp/kubeconfig
      manifests:
        - apiVersion: v1
          kind: Namespace
          metadata:
            name: "{{ .vars.namespace }}"
      provision:
        default: cluster
        targets:
          cluster:
            kind: kubernetes
          deployment-repo:
            kind: git
            repository: deployments
            path: "clusters/{{ .vars.cluster }}/argocd"

Kubernetes components use the same stack sections as other component types — vars, env, auth, metadata, settings, dependencies, hooks, generate, source/provision, inheritance, and overrides. Kubernetes components do not support command — provider names describe manifest behavior, and Atmos never shells out to kubectl/kustomize.

FieldPurpose
providerkubectl (plain YAML/JSON) or kustomize (Kustomize overlays). Defaults to atmos.yaml components.kubernetes.provider (default kubectl).
pathsFiles or directories relative to the component directory. Directories are walked recursively for .yaml/.yml/.json. With provider: kustomize, a directory containing a Kustomize file is rendered as a Kustomize root.
manifestsInline Kubernetes objects (or YAML strings), merged with objects loaded from paths.
renderDefault output for atmos kubernetes render (output.path, output.split).
provisionDelivery targets for apply/deploy — the cluster (default) or an external target such as a Git deployment repository.
Providers
ProviderBehavior
kubectlLoads plain YAML/JSON manifests from files, directories, and inline manifests.
kustomizeRenders Kustomize directories via the Kustomize Go API, then passes objects to the same Kubernetes clients.

Both providers are Go-SDK-based; neither requires the matching CLI binary installed.

Commands

CommandPurpose
atmos kubernetes render <component> -s <stack>Resolve stack config, run generation, load manifests, render provider inputs, write final YAML. Does not contact the API server.
atmos kubernetes validate <component> -s <stack>Offline structural checks by default (apiVersion/kind present, metadata.name valid DNS-1123, resolvable GVK); --server adds a live server-side dry-run apply. Reports every invalid object, not just the first.
atmos kubernetes diff <component> -s <stack>Server-side dry-run apply against the live object, normalizes volatile metadata, reports created/changed/no-change per object with a unified diff. plan is an alias.
atmos kubernetes apply <component> -s <stack>Resolves each object GVK→GVR via discovery/RESTMapper, applies via the dynamic client with server-side apply, or delivers to a --target provision target.
atmos kubernetes deploy <component> -s <stack>Alias for apply; use when automation language should read as an application deployment rather than an API operation.
atmos kubernetes delete <component> -s <stack>Deletes the rendered objects from the cluster.

All operation commands accept --all, --affected (with --base/--ref/--sha/--repo-path/ --clone-target-ref/--ssh-key/--ssh-key-password), and --include-dependents, matching atmos describe affected semantics. --all/--affected are mutually exclusive with a positional component argument. kubernetes aliases to k8s.

render output

render writes multi-document YAML to stdout by default. --output <file> writes a single file; --output-dir <dir> (with optional --split) writes one file per object (or manifest.yaml without --split). These flags only work rendering a single component — set component-level render.output for --all/--affected runs.

validate

Runs the same offline structural checks automatically before apply/deploy, so malformed manifests are rejected before anything reaches the cluster or a provision target. --server additionally requires a reachable cluster/kubeconfig and surfaces schema errors and missing CRDs authoritatively.

Show full SKILL.md (369 more words)Show less
diff

atmos kubernetes diff does not shell out to kubectl diff. Secret objects are omitted from diff output and CI summaries.

Provision Targets (GitOps delivery)

By default apply/deploy applies to the cluster (kind: kubernetes). A component can instead publish rendered manifests to a Git deployment repository reconciled by Argo CD/Flux (kind: git):

yaml
git:
  repositories:
    deployments:
      uri: https://github.com/acme/deployments.git
      branch: main

components:
  kubernetes:
    argocd:
      provision:
        default: cluster                 # used when --target is omitted
        targets:
          cluster:
            kind: kubernetes
          deployment-repo:
            kind: git
            repository: deployments      # references git.repositories.<name>
            path: "clusters/{{ .vars.cluster }}/argocd"
            auth:
              identity: platform-admin   # optional; else the repository default
            commit:
              message: "Render {{ .vars.app_name }} for {{ .vars.stage }}"
              signing: auto              # auto | always | never
shell
atmos kubernetes deploy argocd -s plat-ue2-dev --target=deployment-repo

The git target clones (or fast-forwards), replaces the managed path with the rendered manifests, commits with provenance trailers (Atmos-Stack, Atmos-Component), and pushes. Re-delivering identical manifests is a clean no-op. Credentials come from Atmos Auth (GitHub STS) — never written into the manifests. Pull-request publishing is not yet supported. See atmos-git for the underlying mechanics.

Auth

Kubernetes operations use whatever kubeconfig/client configuration is visible to the Kubernetes Go client; Atmos Auth prepares that environment before the SDK client is created.

Local/ambient clusters:

yaml
auth:
  identities:
    local-k3s:
      kind: ambient

components:
  kubernetes:
    app:
      env:
        KUBECONFIG: /path/to/kubeconfig

EKS clusters — chain an aws/eks integration off an AWS identity to resolve the cluster and write kubeconfig before the Kubernetes command runs:

yaml
auth:
  identities:
    platform-admin:
      kind: aws
  integrations:
    prod/eks:
      kind: aws/eks
      via:
        identity: platform-admin
      spec:
        cluster:
          name: acme-prod-eks
          region: us-east-1
          kubeconfig:
            path: /tmp/acme-prod-kubeconfig
            update: replace

See atmos-aws-eks for the full aws/eks integration contract.

atmos.yaml Configuration

yaml
components:
  kubernetes:
    base_path: components/kubernetes    # default: components/kubernetes
    provider: kubectl                   # default provider: kubectl | kustomize
    auto_generate_files: false          # render component `generate:` before operations

Native CI Summaries

When ci.enabled: true and Atmos runs in a supported CI provider (e.g. GitHub Actions), Kubernetes commands write a compact Markdown job summary ($GITHUB_STEP_SUMMARY) — summaries only (no $GITHUB_OUTPUT, commit statuses, PR comments, or artifacts):

CommandSummary content
renderRendered objects.
plan/diffCreated/changed/no-change counts, plus a collapsible Kubernetes Diff block (per-object unified diff; Secret objects omitted).
apply/deployApplied or delivered objects.
deleteDeleted and not-found objects.
validateValid and invalid objects.

Hooks

Dotted lifecycle events: before/after × kubernetes.{render,plan,diff,apply,deploy,delete,validate}. plan normalizes to the diff lifecycle and deploy normalizes to the apply lifecycle for hook matching, so hooks written for either spelling match the equivalent operation.

yaml
components:
  kubernetes:
    argocd:
      hooks:
        notify:
          events:
            - after.kubernetes.apply
          command: echo "applied argocd"

Guidance

  • Use validate (offline by default) before wiring --server dry-run checks that need a reachable cluster — it catches structural errors (bad apiVersion/kind, invalid metadata.name) for free.
  • Use dependencies.components so --all/--affected apply objects across components in the right order.
  • Use provision.targets with kind: git for GitOps delivery instead of ad hoc scripts that render and commit manifests manually.
  • Prefer kustomize provider when component paths are Kustomize roots; use kubectl provider for plain manifest files/directories — both avoid needing the matching CLI binary installed.
  • Remember Secret objects never appear in diff output or CI summaries — don't rely on diff/CI logs to review secret contents.

© cloudposse, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in agent-skills/skills/atmos-kubernetes of cloudposse/atmos.

Open the folder on GitHubat commit 36726ae

Compare with similar skills

Atmos Kubernetes next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Atmos Kubernetes compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Atmos Kubernetes this skillcloudposse/atmos1.4k—~2.8kAutomated safety check: PassApache-2.0
Keloskelos-dev/kelos336—~1.3kAutomated safety check: PassApache-2.0
GitOps with ArgoCD and Fluxwshobson/agents40k12 repos~1.5kAutomated safety check: PassMIT
HypaHypabolic/Hypa208—~2.6kAutomated safety check: PassCustom licence
Tokf Runmpecan/tokf199—~571Automated safety check: PassMIT
Argocd GitopsBagelHole/DevOps-Security-Agent-Skills1.1k—~2.4kAutomated safety check: PassMIT

Similar skills

  • Kelos

    kelos-dev/kelos

    Install and configure Kelos; author, document, inspect, troubleshoot, and operate its Kubernetes custom resources and CRD schemas in the kelos.dev API group using manifests, kubectl, or the kelos CLI.

    336 GitHub stars~1.3k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Sets up GitOps continuous delivery for Kubernetes with ArgoCD or Flux, covering installation, repository layout, sync policies, progressive delivery and secrets.

    40k GitHub starsUsed in 12 repos~1.5k tokens
    DevOps & CloudAuto-check passed
  • Hypa

    Hypabolic/Hypa

    Context-optimized command runtime. An agent skill from Hypabolic/Hypa.

    208 GitHub stars~2.6k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Tokf Run

    mpecan/tokf

    Compress verbose CLI output with tokf before returning results.

    199 GitHub stars~571 tokensUpdated today
    DevOps & CloudAuto-check passed
  • Argocd Gitops

    BagelHole/DevOps-Security-Agent-Skills

    Implement GitOps with ArgoCD for declarative Kubernetes deployments.

    1.1k GitHub stars~2.4k tokensUpdated 4 mo ago
    DevOps & CloudAuto-check passed
  • Alloy

    grafana/skills

    Official

    Build a unified telemetry pipeline with Grafana Alloy — one OpenTelemetry-compatible binary that collects metrics, logs, traces, and profiles and ships to Grafana Cloud / Prometheus / Loki / Tempo /…

    279 GitHub stars~1.3k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed

More from cloudposse/atmos

All 70 skills in this repo
  • Fix Log

    cloudposse/atmos

    A skill your agent uses when implementing, finishing, documenting, or reviewing a fix, repair, remediation, bug fix, debug-and-fix task, workflow fix, infrastructure fix, or any change that should…

    1.4k GitHub stars~685 tokensUpdated today
    Auto-check passed
  • Atmos Lint

    cloudposse/atmos

    Atmos Terraform linting with TFLint: standalone atmos terraform lint, component-aware config discovery and toolchain versions, TFLint rule configuration, and lifecycle hooks/CI findings.

    1.4k GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Changelog

    cloudposse/atmos

    Blog post authoring for Atmos: MDX template, frontmatter, website/blog/tags.yml and authors.yml rules, problem-first framing, backtick-opening ban, optional cast embeds, and no-Go-internals leakage.

    1.4k GitHub stars~2.7k tokensUpdated today
    Auto-check passed
  • Editions

    cloudposse/atmos

    Decide whether a PR's new or changed default needs edition-journal handling (pkg/edition, docs/prd/editions.md), and do the mechanical work if so: journal entries, the four-layer default check…

    1.4k GitHub stars~2.1k tokensUpdated today
    Auto-check passed
  • Atmos Migration

    cloudposse/atmos

    Migrate to Atmos from native Terraform, Terraform Workspaces, Terramate, Terragrunt, Make, Just, or Task; migrate tool versions from mise or Aqua CLI; migrate AWS/GCP/Azure CLI configs, Leapp…

    1.4k GitHub stars~5.1k tokensUpdated today
    Auto-check: warnings
  • PR Maintenance Loop

    cloudposse/atmos

    Start an hourly background loop that keeps the current branch's PR rebased, its addressed CodeRabbit threads resolved, its CI checks passing, its lint clean, its tests passing with adequate patch…

    1.4k GitHub stars~1.4k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Atmos Kubernetes

What does Atmos Kubernetes do?

Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers…. Atmos Kubernetes is an agent skill from cloudposse/atmos.kubernetes, kubectl/kustomize providers, paths/manifests, provision targets (cluster vs.

When should I use Atmos Kubernetes?

Atmos Kubernetes fits situations like: tasks that involve Container orchestration.

How do I install Atmos Kubernetes in Claude Code?

Run `npx skills add cloudposse/atmos --skill atmos-kubernetes -a claude-code`. Or copy the skill folder (agent-skills/skills/atmos-kubernetes in cloudposse/atmos) into .claude/skills/atmos-kubernetes in your project. Claude Code loads it when a task matches its description.

How do I install Atmos Kubernetes in Codex?

Run `npx skills add cloudposse/atmos --skill atmos-kubernetes -a codex`. Or copy the skill folder (agent-skills/skills/atmos-kubernetes in cloudposse/atmos) into .agents/skills/atmos-kubernetes in your project. Codex loads it when a task matches its description.

Can I use Atmos Kubernetes in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add cloudposse/atmos --skill atmos-kubernetes -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/atmos-kubernetes, .gemini/skills/atmos-kubernetes, .github/skills/atmos-kubernetes and .opencode/skills/atmos-kubernetes in your project.

What does Atmos Kubernetes need to run?

Going by SKILL.md and its folder, Atmos Kubernetes needs the command-line tools its instructions call (kubectl).

Does Atmos Kubernetes access the network?

SKILL.md names 1 domain. In commands or code: github.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Atmos Kubernetes safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Atmos Kubernetes use?

Atmos Kubernetes is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Atmos Kubernetes use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Atmos Kubernetes?

Skills that share tags, products or a category with Atmos Kubernetes: Kelos (kelos-dev/kelos, 336 stars), GitOps with ArgoCD and Flux (wshobson/agents, 40k stars), Hypa (Hypabolic/Hypa, 208 stars) and Tokf Run (mpecan/tokf, 199 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Atmos Kubernetes?

cloudposse (a GitHub organization) maintains it in cloudposse/atmos, which has 1,396 GitHub stars. The repository holds 70 skills in this directory. The repository was last updated on October 8, 2026.

Source: cloudposse/atmos on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.