Agent skill

Atmos Ansible

by cloudposse in cloudposse/atmos

Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management

Apache-2.0Auto-check passedDevOps & Cloud

Install Atmos Ansible

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

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

GitHub CLI
$ gh skill install cloudposse/atmos atmos-ansible --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-ansible .claude/skills/atmos-ansible && 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-ansible
GitHub stars
1.4k
Token cost
~3.6k tokens
SKILL.md length
858 words
Files
2 (incl. references)
Skills in repo
70
Repo updated
First seen
Licence
Apache-2.0

At a glance

Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management

  • Works in 7 steps: Resolves stack configuration -- Reads… → Generates a variables file -- Writes a… → Resolves the playbook -- Determines the… → …
  • Tasks that involve Infrastructure as code
  • SKILL.md covers How Atmos Orchestrates Ansible, Core Commands, Stack Configuration and Variable Handling, plus 9 more sections
  • Calls ansible

What it does

Atmos Ansible is an agent skill from cloudposse/atmos. Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management

Its SKILL.md is about 3.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/commands-reference.md`).

It sits in DevOps & Cloud, covering Infrastructure as code. It works with Ansible. 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 Infrastructure as code

Example prompts

  • “/atmos-ansible”

Requirements

  • Python 3

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Resolves stack configuration -- Reads and deep-merges all stack manifests to produce the fully resolved
  2. Generates a variables file -- Writes a YAML file containing all vars defined for the component in the
  3. Resolves the playbook -- Determines the playbook to run from --playbook flag or
  4. Resolves the inventory -- Determines the inventory source from --inventory flag or
  5. Sets environment variables -- Applies all env settings from the stack manifest.
  6. Executes ansible-playbook -- Runs the playbook in the component directory, passing the generated
  7. Cleans up -- Removes the generated variables file after execution completes.

What it can do on your machine

Read from SKILL.md and the folder at commit fbae93f. 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:

    • ansible

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

  • Network

    No URLs in SKILL.md.

    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 Ansible loads about 3.6k tokens when it runs, and up to ~6.3k if it reads all its reference files. Until then it costs about 38 tokens; SKILL.md has 858 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~38
When it runs · the whole SKILL.md, loaded when a task matches
~3.6k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~6.3k

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 fbae93f, republished under its Apache-2.0 licence (© cloudposse). 858 words, ~3,575 tokens.

Download SKILL.mdSave it as .claude/skills/atmos-ansible/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
atmos-ansible
description
Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management
metadata.copyright
Copyright Cloud Posse, LLC 2026
metadata.version
1.0.0
metadata.category
orchestrators

Atmos Ansible Orchestration

Atmos wraps the Ansible CLI to provide stack-aware orchestration of configuration management operations. Instead of manually managing variables, inventory, and playbook paths for each Ansible component, Atmos resolves the full configuration from stack manifests and handles all of these concerns automatically.

Note: atmos ansible playbook is designed for interactive operator sessions where a human is present to monitor output, respond to prompts, and approve changes. It is not suitable for headless CI/CD automation where no interactive terminal is available. For automated pipelines, use a dedicated Ansible CI runner or invoke ansible-playbook directly from a CI step with pre-exported credentials.

How Atmos Orchestrates Ansible

When you run atmos ansible playbook, Atmos performs the following sequence:

  1. Resolves stack configuration -- Reads and deep-merges all stack manifests to produce the fully resolved configuration for the target component in the target stack.
  2. Generates a variables file -- Writes a YAML file containing all vars defined for the component in the stack, following the naming convention <context>-<component>.ansible.vars.yaml.
  3. Resolves the playbook -- Determines the playbook to run from --playbook flag or settings.ansible.playbook in the stack manifest.
  4. Resolves the inventory -- Determines the inventory source from --inventory flag or settings.ansible.inventory in the stack manifest.
  5. Sets environment variables -- Applies all env settings from the stack manifest.
  6. Executes ansible-playbook -- Runs the playbook in the component directory, passing the generated variables file via --extra-vars @<varfile> and any additional native flags.
  7. Cleans up -- Removes the generated variables file after execution completes.

This means a single command like atmos ansible playbook webserver -s prod replaces what would normally require finding the right playbook, constructing extra-vars, specifying inventory, and managing environment variables manually.

Core Commands

playbook

Run an Ansible playbook for a component in a stack.

shell
atmos ansible playbook <component> -s <stack> [flags] [-- ansible-options]
shell
# Basic playbook execution
atmos ansible playbook webserver -s prod

# Specify playbook explicitly (overrides stack manifest)
atmos ansible playbook webserver -s prod --playbook deploy.yml

# Specify both playbook and inventory
atmos ansible playbook webserver -s prod -p site.yml -i inventory/production

# Dry run (shows command without executing)
atmos ansible playbook webserver -s prod --dry-run

# Pass native ansible-playbook flags after --
atmos ansible playbook webserver -s prod -- --check
atmos ansible playbook webserver -s prod -- -vvv
atmos ansible playbook webserver -s prod -- --limit "web01,web02"
atmos ansible playbook webserver -s prod -- --tags "deploy,config"
atmos ansible playbook webserver -s prod -- --skip-tags "slow"
atmos ansible playbook webserver -s prod -- --extra-vars "version=1.2.3"
version

Display the installed Ansible version and configuration information.

shell
atmos ansible version

This runs ansible --version and shows the Ansible version, configuration file location, module search path, Python version, and other details.

Stack Configuration

Component Schema

Ansible components live under components.ansible in stack manifests:

yaml
components:
  ansible:
    <component_name>:
      vars: {}              # Variables passed via --extra-vars
      env: {}               # Environment variables during execution
      settings:
        ansible:
          playbook: <file>  # Playbook file to run
          inventory: <src>  # Inventory source (file, directory, or script)
      metadata: {}          # Component behavior and inheritance
      command: ansible      # Override ansible binary
      hooks: {}             # Lifecycle event handlers
Minimal Example
yaml
components:
  ansible:
    hello-world:
      vars:
        app_name: my-app
        app_version: "1.0.0"
        app_port: 8080
      settings:
        ansible:
          playbook: site.yml
          inventory: inventory.ini
Complete Stack Example
yaml
import:
  - catalog/ansible/_defaults
  - orgs/acme/plat/prod/_defaults

vars:
  region: us-east-1
  stage: prod

ansible:
  vars:
    managed_by: Atmos
  env:
    # Security note: Setting ANSIBLE_HOST_KEY_CHECKING to "false" disables SSH host key verification,
    # which exposes connections to man-in-the-middle attacks. Only use this in controlled environments
    # (e.g., ephemeral CI environments with known-clean network paths). For production environments,
    # maintain and distribute a known_hosts file or use the ansible_ssh_extra_args approach with
    # StrictHostKeyChecking=accept-new to accept keys on first connection only.
    ANSIBLE_HOST_KEY_CHECKING: "false"

components:
  ansible:
    webserver:
      vars:
        app_name: myapp
        app_port: 8080
        app_version: "2.0.0"
      settings:
        ansible:
          playbook: site.yml
          inventory: inventory/production

    database:
      metadata:
        component: database
      vars:
        db_name: acme-prod
        db_port: 5432
      settings:
        ansible:
          playbook: deploy.yml
          inventory: inventory/production
      dependencies:
        components:
          - component: webserver
Component-Type Defaults

Define defaults that apply to all Ansible components in a stack:

yaml
# These apply to all Ansible components
ansible:
  vars:
    managed_by: Atmos
  env:
    # Security note: ANSIBLE_HOST_KEY_CHECKING: "false" disables SSH host key verification and should
    # only be used in controlled environments. For production, use a known_hosts file instead.
    ANSIBLE_HOST_KEY_CHECKING: "false"
    ANSIBLE_FORCE_COLOR: "true"

# Individual components inherit and can override
components:
  ansible:
    webserver:
      vars:
        app_port: 8080

Variable Handling

Atmos generates a YAML file from the vars section and passes it to ansible-playbook using --extra-vars @<filename>. All stack variables become available directly in playbooks.

The generated file follows the naming convention: <context>-<component>.ansible.vars.yaml

For example, for component webserver with context prefix acme-plat-prod-us-east-1, the file is: acme-plat-prod-us-east-1-webserver.ansible.vars.yaml

Stack Variables in Playbooks
yaml
# Stack manifest
components:
  ansible:
    webserver:
      vars:
        app_name: myapp
        app_port: 8080
yaml
# Playbook references variables directly
- name: Deploy app
  hosts: webservers
  tasks:
    - name: Show config
      ansible.builtin.debug:
        msg: "Deploying {{ app_name }} on port {{ app_port }}"

Playbook and Inventory Resolution

The playbook and inventory can be specified in two ways. Command-line flags always take precedence over stack manifest settings.

Resolution order (highest to lowest priority):

  1. Command-line flags: --playbook / -p and --inventory / -i
  2. Stack manifest: settings.ansible.playbook and settings.ansible.inventory
yaml
# Stack manifest (lower priority)
components:
  ansible:
    webserver:
      settings:
        ansible:
          playbook: site.yml
          inventory: inventory/production
shell
# Command-line override (higher priority)
atmos ansible playbook webserver -s prod --playbook deploy.yml -i inventory/staging

Configuration in atmos.yaml

Configure Ansible behavior in atmos.yaml:

yaml
components:
  ansible:
    # Executable to run
    command: ansible

    # Base path to Ansible components
    base_path: components/ansible
Configuration Reference
  • command -- Executable to run for Ansible commands. Defaults to ansible. Supports absolute paths (e.g., /usr/local/bin/ansible or /opt/venv/bin/ansible).
  • base_path -- Directory containing Ansible component directories. Each subdirectory should contain playbooks and related files (roles, inventory, etc.).
Component Directory Structure
text
components/ansible/
  hello-world/
    site.yml
    inventory.ini
  webserver/
    site.yml
    roles/
      nginx/
    inventory/
      production
      staging
  database/
    deploy.yml
    inventory.ini
Show full SKILL.md (368 more words)Show less

Path-Based Component Resolution

Use filesystem paths instead of component names for convenience:

shell
# Navigate to component directory and use current directory
cd components/ansible/webserver
atmos ansible playbook . -s prod

# Relative path from components/ansible
cd components/ansible
atmos ansible playbook ./webserver -s prod

# From project root with relative path
atmos ansible playbook components/ansible/webserver -s prod

# Combine with other flags
cd components/ansible/webserver
atmos ansible playbook . -s prod --playbook deploy.yml --inventory production

Supported path formats:

  • . -- Current directory
  • ./component -- Relative path from current directory
  • ../other-component -- Relative path to sibling directory
  • /absolute/path/to/component -- Absolute path

Requirements:

  • Must be inside a component directory under the configured base path.
  • Must specify --stack flag.
  • Component must exist in the specified stack configuration.
  • The component path must resolve to a unique component name. If multiple components reference the same path, use the unique component name instead.

Environment Variables

Common environment variables for Ansible components configured via env:

  • ANSIBLE_HOST_KEY_CHECKING -- Controls SSH host key verification. Prefer "true" in production; only set to "false" in ephemeral or development environments with explicit risk acceptance.
  • ANSIBLE_FORCE_COLOR -- Force colored output (set to true).
  • ANSIBLE_CONFIG -- Path to Ansible configuration file.
  • ANSIBLE_VAULT_PASSWORD_FILE -- Path to Ansible Vault password file.
  • ANSIBLE_ROLES_PATH -- Additional paths to search for roles.
  • ANSIBLE_COLLECTIONS_PATH -- Paths to search for collections.
yaml
components:
  ansible:
    webserver:
      env:
        # Only disable host key checking in dev/ephemeral environments (see security note above)
        ANSIBLE_HOST_KEY_CHECKING: "false"
        ANSIBLE_FORCE_COLOR: "true"
        ANSIBLE_VAULT_PASSWORD_FILE: /path/to/vault-password

Native Flag Passthrough

Any flags placed after -- are passed directly to ansible-playbook:

shell
# Check mode (dry run at Ansible level)
atmos ansible playbook webserver -s prod -- --check

# Verbose output
atmos ansible playbook webserver -s prod -- -vvv

# Limit to specific hosts
atmos ansible playbook webserver -s prod -- --limit "web01,web02"

# Run specific tags
atmos ansible playbook webserver -s prod -- --tags "deploy"

# Skip specific tags
atmos ansible playbook webserver -s prod -- --skip-tags "slow"

# Additional extra variables (on top of those generated by Atmos)
atmos ansible playbook webserver -s prod -- --extra-vars "version=1.2.3"

# Combine multiple native flags
atmos ansible playbook webserver -s prod -- --check --diff --limit web01 -vv

Stack Inheritance and Imports

Ansible components support the same inheritance model as other Atmos component types:

yaml
# stacks/catalog/hello-world.yaml (shared defaults)
components:
  ansible:
    hello-world:
      vars:
        app_name: my-app
        app_version: "1.0.0"
        app_port: 8080
      settings:
        ansible:
          playbook: site.yml
          inventory: inventory.ini
yaml
# stacks/deploy/dev.yaml (environment override)
import:
  - catalog/hello-world

vars:
  stage: dev

components:
  ansible:
    hello-world:
      vars:
        app_version: "1.0.0-dev"
yaml
# stacks/deploy/prod.yaml (environment override)
import:
  - catalog/hello-world

vars:
  stage: prod

components:
  ansible:
    hello-world:
      vars:
        app_version: "2.0.0"
        app_port: 443

Debugging

Describe Component

Use atmos describe component to see the fully resolved configuration:

shell
atmos describe component hello-world -s dev --type ansible
Dry Run

Preview what Atmos will do without executing:

shell
atmos ansible playbook webserver -s prod --dry-run

Best Practices

Interactive use only: atmos ansible playbook is intended for interactive operator sessions, not headless CI/CD automation. Ensure a human is present to monitor output and respond to any interactive prompts. For fully automated pipelines, invoke ansible-playbook directly from a CI step.

  1. Use stack manifest settings for playbook configuration. Define settings.ansible.playbook and settings.ansible.inventory rather than passing flags every time.

  2. Centralize defaults in catalog files. Define common settings in catalog defaults and override only what differs per environment.

  3. Use dependencies.components for ordering. Define dependencies when playbooks need to run after infrastructure is provisioned, such as after Terraform components.

  4. Keep playbooks focused. Create small, task-specific playbooks rather than monolithic automation.

  5. Use env for Ansible configuration. Configure Ansible behavior through environment variables rather than ansible.cfg for consistency across environments.

  6. Leverage inheritance. Use abstract components and inheritance for shared playbook configurations across environments.

  7. Use --dry-run before production runs. Preview the commands Atmos will execute before running against production infrastructure.

Additional Resources

© 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

SKILL.md and 1 other file (references) in agent-skills/skills/atmos-ansible of cloudposse/atmos.

  • SKILL.md
  • references/commands-reference.md

Open the folder on GitHubat commit fbae93f

Compare with similar skills

Atmos Ansible 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 Ansible compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Atmos Ansible this skillcloudposse/atmos1.4k—~3.6kAutomated safety check: PassApache-2.0
Wdio Testingansible/vscode-ansible488—~2.2kAutomated safety check: PassMIT
Spa Create Configsplunk/splunk-platform-automator138—~3.5kAutomated safety check: PassProprietary
Spa Add Test Scenariosplunk/splunk-platform-automator138—~2.2kAutomated safety check: PassProprietary
Frontend Overlayansible/ansible-ui113—~2.5kAutomated safety check: NotesApache-2.0
Run Testsansible-collections/ansible.mysql134—~1.2kAutomated safety check: PassCustom licence

Similar skills

  • Wdio Testing

    ansible/vscode-ansible

    Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.

    488 GitHub stars~2.2k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Spa Create Config

    splunk/splunk-platform-automator

    A skill your agent uses when creating or updating splunkconfig.yml, designing Splunk Enterprise lab topology, multisite IDXC, SHC layout, architecture plan before config, or AWS Terraform block for…

    138 GitHub stars~3.5k tokensUpdated 3 days ago
    DevOps & CloudAuto-check passed
  • Spa Add Test Scenario

    splunk/splunk-platform-automator

    A skill your agent uses when adding app scope/routing test coverage (deployer, CM, DS, direct).

    138 GitHub stars~2.2k tokensUpdated 3 days ago
    DevOps & CloudAuto-check passed
  • Frontend Overlay

    ansible/ansible-ui

    Product-specific frontend wrappers, API clients, and paths for ansible-ui.

    113 GitHub stars~2.5k tokensUpdated yesterday
    DevOps & CloudAuto-check: notes
  • Run Tests

    ansible-collections/ansible.mysql

    Runs and writes tests (sanity, unit, integration) for the ansible.mysql Ansible collection using ansible-test.

    134 GitHub stars~1.2k tokensUpdated 3 days ago
    DevOps & CloudAuto-check passed
  • Ansible Module Doc Review

    ansible-collections/vmware.vmware_rest

    Review and enrich Ansible module documentation to ensure completeness and quality.

    147 GitHub stars~3k tokensUpdated 7 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 yesterday
    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 yesterday
    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 yesterday
    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 yesterday
    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 yesterday
    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 yesterday
    Auto-check passed

Works with

Categories

Questions about Atmos Ansible

What does Atmos Ansible do?

Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management. Atmos Ansible is an agent skill from cloudposse/atmos.

When should I use Atmos Ansible?

Atmos Ansible fits situations like: tasks that involve Infrastructure as code.

How do I install Atmos Ansible in Claude Code?

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

How do I install Atmos Ansible in Codex?

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

Can I use Atmos Ansible 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-ansible -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-ansible, .gemini/skills/atmos-ansible, .github/skills/atmos-ansible and .opencode/skills/atmos-ansible in your project.

What does Atmos Ansible need to run?

Going by SKILL.md and its folder, Atmos Ansible needs the command-line tools its instructions call (ansible). Our summary lists: Python 3.

Does Atmos Ansible access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Atmos Ansible 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 Ansible use?

Atmos Ansible 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 Ansible use?

About 3.6k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.8k tokens, read only when the agent opens those files.

What are the alternatives to Atmos Ansible?

Skills that share tags, products or a category with Atmos Ansible: Wdio Testing (ansible/vscode-ansible, 488 stars), Spa Create Config (splunk/splunk-platform-automator, 138 stars), Spa Add Test Scenario (splunk/splunk-platform-automator, 138 stars) and Frontend Overlay (ansible/ansible-ui, 113 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Atmos Ansible?

cloudposse (a GitHub organization) maintains it in cloudposse/atmos, which has 1,398 GitHub stars. The repository holds 70 skills in this directory. The repository was last updated on October 9, 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.