Wdio Testing
ansible/vscode-ansible
Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.
Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management
$ npx skills add cloudposse/atmos --skill atmos-ansible -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install cloudposse/atmos atmos-ansible --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "atmos-ansible" agent skill from https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansible into .claude/skills/atmos-ansible/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "atmos-ansible", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansibleType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add cloudposse/atmos --skill atmos-ansible -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install cloudposse/atmos atmos-ansible --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/cloudposse/atmos.git skills-src && mkdir -p .agents/skills && cp -r skills-src/agent-skills/skills/atmos-ansible .agents/skills/atmos-ansible && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "atmos-ansible" agent skill from https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansible into .agents/skills/atmos-ansible/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "atmos-ansible", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add cloudposse/atmos --skill atmos-ansible -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install cloudposse/atmos atmos-ansible --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/cloudposse/atmos.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/agent-skills/skills/atmos-ansible .cursor/skills/atmos-ansible && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "atmos-ansible" agent skill from https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansible into .cursor/skills/atmos-ansible/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "atmos-ansible", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/cloudposse/atmos.git --path agent-skills/skills/atmos-ansible--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add cloudposse/atmos --skill atmos-ansible -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install cloudposse/atmos atmos-ansible --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/cloudposse/atmos.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/agent-skills/skills/atmos-ansible .gemini/skills/atmos-ansible && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "atmos-ansible" agent skill from https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansible into .gemini/skills/atmos-ansible/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "atmos-ansible", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install cloudposse/atmos atmos-ansibleInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add cloudposse/atmos --skill atmos-ansible -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/cloudposse/atmos.git skills-src && mkdir -p .github/skills && cp -r skills-src/agent-skills/skills/atmos-ansible .github/skills/atmos-ansible && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "atmos-ansible" agent skill from https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansible into .github/skills/atmos-ansible/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "atmos-ansible", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add cloudposse/atmos --skill atmos-ansible -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install cloudposse/atmos atmos-ansible --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/cloudposse/atmos.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/agent-skills/skills/atmos-ansible .opencode/skills/atmos-ansible && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "atmos-ansible" agent skill from https://github.com/cloudposse/atmos/tree/main/agent-skills/skills/atmos-ansible into .opencode/skills/atmos-ansible/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "atmos-ansible", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
atmos-ansibleAnsible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management
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.
7 steps, taken from the first numbered list in SKILL.md.
Read from SKILL.md and the folder at commit fbae93f. It shows what the files ask for, not the result of running them.
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.
Shell commands in SKILL.md call:
ansibleFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
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.
The full file from cloudposse/atmos at commit fbae93f, republished under its Apache-2.0 licence (© cloudposse). 858 words, ~3,575 tokens.
.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.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 playbookis 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 invokeansible-playbookdirectly from a CI step with pre-exported credentials.
When you run atmos ansible playbook, Atmos performs the following sequence:
vars defined for the component in the
stack, following the naming convention <context>-<component>.ansible.vars.yaml.--playbook flag or
settings.ansible.playbook in the stack manifest.--inventory flag or
settings.ansible.inventory in the stack manifest.env settings from the stack manifest.ansible-playbook -- Runs the playbook in the component directory, passing the generated
variables file via --extra-vars @<varfile> and any additional native flags.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.
Run an Ansible playbook for a component in a stack.
atmos ansible playbook <component> -s <stack> [flags] [-- ansible-options]# 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"Display the installed Ansible version and configuration information.
atmos ansible versionThis runs ansible --version and shows the Ansible version, configuration file location, module search path,
Python version, and other details.
Ansible components live under components.ansible in stack manifests:
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 handlerscomponents:
ansible:
hello-world:
vars:
app_name: my-app
app_version: "1.0.0"
app_port: 8080
settings:
ansible:
playbook: site.yml
inventory: inventory.iniimport:
- 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: webserverDefine defaults that apply to all Ansible components in a stack:
# 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: 8080Atmos 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 manifest
components:
ansible:
webserver:
vars:
app_name: myapp
app_port: 8080# Playbook references variables directly
- name: Deploy app
hosts: webservers
tasks:
- name: Show config
ansible.builtin.debug:
msg: "Deploying {{ app_name }} on port {{ app_port }}"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):
--playbook / -p and --inventory / -isettings.ansible.playbook and settings.ansible.inventory# Stack manifest (lower priority)
components:
ansible:
webserver:
settings:
ansible:
playbook: site.yml
inventory: inventory/production# Command-line override (higher priority)
atmos ansible playbook webserver -s prod --playbook deploy.yml -i inventory/stagingConfigure Ansible behavior in atmos.yaml:
components:
ansible:
# Executable to run
command: ansible
# Base path to Ansible components
base_path: components/ansiblecommand -- 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.).components/ansible/
hello-world/
site.yml
inventory.ini
webserver/
site.yml
roles/
nginx/
inventory/
production
staging
database/
deploy.yml
inventory.iniUse filesystem paths instead of component names for convenience:
# 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 productionSupported path formats:
. -- Current directory./component -- Relative path from current directory../other-component -- Relative path to sibling directory/absolute/path/to/component -- Absolute pathRequirements:
--stack flag.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.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-passwordAny flags placed after -- are passed directly to ansible-playbook:
# 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 -vvAnsible components support the same inheritance model as other Atmos component types:
# 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# stacks/deploy/dev.yaml (environment override)
import:
- catalog/hello-world
vars:
stage: dev
components:
ansible:
hello-world:
vars:
app_version: "1.0.0-dev"# 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: 443Use atmos describe component to see the fully resolved configuration:
atmos describe component hello-world -s dev --type ansiblePreview what Atmos will do without executing:
atmos ansible playbook webserver -s prod --dry-runInteractive use only:
atmos ansible playbookis 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, invokeansible-playbookdirectly from a CI step.
Use stack manifest settings for playbook configuration. Define settings.ansible.playbook and
settings.ansible.inventory rather than passing flags every time.
Centralize defaults in catalog files. Define common settings in catalog defaults and override only what differs per environment.
Use dependencies.components for ordering. Define dependencies when playbooks need to run
after infrastructure is provisioned, such as after Terraform components.
Keep playbooks focused. Create small, task-specific playbooks rather than monolithic automation.
Use env for Ansible configuration. Configure Ansible behavior through environment variables
rather than ansible.cfg for consistency across environments.
Leverage inheritance. Use abstract components and inheritance for shared playbook configurations across environments.
Use --dry-run before production runs. Preview the commands Atmos will execute before running
against production infrastructure.
© 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
SKILL.md and 1 other file (references) in agent-skills/skills/atmos-ansible of cloudposse/atmos.
Open the folder on GitHubat commit fbae93f
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Atmos Ansible this skillcloudposse/atmos | 1.4k | — | ~3.6k | Automated safety check: Pass | Apache-2.0 | |
| Wdio Testingansible/vscode-ansible | 488 | — | ~2.2k | Automated safety check: Pass | MIT | |
| Spa Create Configsplunk/splunk-platform-automator | 138 | — | ~3.5k | Automated safety check: Pass | Proprietary | |
| Spa Add Test Scenariosplunk/splunk-platform-automator | 138 | — | ~2.2k | Automated safety check: Pass | Proprietary | |
| Frontend Overlayansible/ansible-ui | 113 | — | ~2.5k | Automated safety check: Notes | Apache-2.0 | |
| Run Testsansible-collections/ansible.mysql | 134 | — | ~1.2k | Automated safety check: Pass | Custom licence |
ansible/vscode-ansible
Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.
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…
splunk/splunk-platform-automator
A skill your agent uses when adding app scope/routing test coverage (deployer, CM, DS, direct).
ansible/ansible-ui
Product-specific frontend wrappers, API clients, and paths for ansible-ui.
ansible-collections/ansible.mysql
Runs and writes tests (sanity, unit, integration) for the ansible.mysql Ansible collection using ansible-test.
ansible-collections/vmware.vmware_rest
Review and enrich Ansible module documentation to ensure completeness and quality.
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…
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.
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.
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…
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…
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…
Works with
Categories
Ansible orchestration: playbook execution, variable passing, inventory management, stack-based configuration for configuration management. Atmos Ansible is an agent skill from cloudposse/atmos.
Atmos Ansible fits situations like: tasks that involve Infrastructure as 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.
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.
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.
Going by SKILL.md and its folder, Atmos Ansible needs the command-line tools its instructions call (ansible). Our summary lists: Python 3.
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.
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.
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.
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.
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.
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.