Atmos is an infrastructure runtime that coordinates tools such as Terraform, OpenTofu, Kubernetes, Helm, Packer, Ansible, and containers through consistent commands and configuration. It is for teams running cloud infrastructure on laptops, in CI, or through AI agents across environments and regions. Its catalogue entries provide skills, agents, commands, and other add-ons for Atmos workflows.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add cloudposse/atmos --skill atmos-testsgit clone --depth 1 https://github.com/cloudposse/atmosWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/cloudposse/atmos/atmos-tests)<a href="https://agentmods.dev/skills/cloudposse/atmos/atmos-tests"><img src="https://agentmods.dev/badge/skills/cloudposse/atmos/atmos-tests/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/cloudposse/atmos/atmos-tests"><img src="https://agentmods.dev/badge/skills/cloudposse/atmos/atmos-tests.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00062 | $0.01709 |
| Opus 5.5 | $0.00025 | $0.00684 |
| Sonnet 5.5 | $0.00012 | $0.00342 |
| Haiku 4.5 | $0.00006 | $0.00171 |
Grade A, and why
atmos-tests scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 26d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
| HTTP status, health endpoint, or response text | `http` with `expect.status` and optionally `expect.response`; prefer this over `curl` and shell parsing. | How it starts
The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Atmos Tests
Use type: test to run smoke tests that validate deployed stacks or other
integration tests. It groups existing typed steps into a test report: passing
logs stay hidden, failures reveal their buffered output, and independent checks
continue by default.
Read patterns for complete custom-command, HTTP, parallel/dependency, matrix, script/interpreter, and post-apply hook examples. Use atmos-steps for shared step fields and the relevant surface skill: custom commands, workflows, or hooks.
Authoring Process
- Inspect the project's commands, workflows, hooks, and existing test scripts. Discover actual stack/component names and deployment outputs before choosing targets. Do not invent endpoints or hard-code credentials.
- Prefer a custom command for a directly invoked suite with its own arguments
or flags. Use a workflow for an existing orchestration sequence, or a lifecycle
hook to run checks after deployment. There is no built-in standalone
atmos testcommand: defining a custom command namedtestcreates that invocation. - Choose the smallest step type that expresses each assertion. A command that
merely prints a response is not an assertion; it must fail when expectations
are unmet. Name cases descriptively and use
titlefor readable display labels. - Keep direct children sequential. Use a sibling
parallelormatrixgroup when cases should run concurrently. Set a concurrency limit suitable for the service and isolate mutable fixtures for each concurrent case. - Keep default failure-only output and continuation unless the test contract requires otherwise. Add bounded retries for eventual consistency; do not use retries to conceal a reproducible assertion failure.
- Verify a passing case and an intentionally failing case against local fixtures or an appropriate test environment. Check the exit status, failure details, continuation, and expanded leaf totals. Restore the intended expectations.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 26d ago First seen · 122 lines · 62 tokens per session scan A 057786232631
atmos-tests is a skill published in the GitHub repository cloudposse/atmos (1,398 stars, last pushed today), licensed Apache-2.0. It adds 62 tokens to every session and 1,709 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-14.
Other skills, from other repositories
hatch3r-qa-validation
E2E validation workflow producing a structured pass/fail report with evidence. Use when running QA validation, acceptance testing, verifying releases, or working on QA E2E validation issues.
Test Quality Inspector
Systematically inspect unit and E2E tests to verify they test the right behavior, provide meaningful coverage, and catch real regressions.
webapp-testing
Automated webapp testing with Playwright. Server management, UI testing, visual debugging, and reconnaissance-first approach.
Condition-Based Waiting
Replace arbitrary timeouts with condition polling for reliable async tests.
e2e-testing
Guide for running end-to-end tests of the Qwen Code CLI, including headless mode, MCP server testing, and API traffic inspection. Use this skill whenever you need to verify CLI behavior with real model calls, reproduce user-reported bugs end-to-end, test MCP tool integrations, or inspect raw API request/response…
terminal-capture
Automates terminal UI screenshot testing for CLI commands. Applies when reviewing PRs that affect CLI output, testing slash commands (/about, /context, /auth, /export), generating visual documentation, or when 'terminal screenshot', 'CLI test', 'visual test', or 'terminal-capture' is mentioned.