Agent skill

Atmos Stores

by cloudposse in cloudposse/atmos

Store backends: AWS SSM, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Redis, Artifactory configuration, hooks integration, cross-component data sharing, atmos store CLI CRUD, type…

Apache-2.0Auto-check passedDevOps & Cloud

Install Atmos Stores

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

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

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

At a glance

Store backends: AWS SSM, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Redis, Artifactory configuration, hooks integration, cross-component data sharing, atmos store CLI CRUD, type…

  • Works in 3 steps: Configure the store in atmos.yaml → Set up hooks on VPC to write outputs… → Read stored values in EKS component
  • DevOps & Cloud work in your project
  • SKILL.md covers When to Use Stores, Configuring Stores in atmos.yaml, Store Provider Configuration and Reading from Stores with YAML…, plus 7 more sections
  • Needs ARTIFACTORY_ACCESS_TOKEN and JFROG_ACCESS_TOKEN

What it does

Atmos Stores is an agent skill from cloudposse/atmos. Store backends: AWS SSM, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Redis, Artifactory configuration, hooks integration, cross-component data sharing, atmos store CLI CRUD, type: store workflow step

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

It sits in DevOps & Cloud. It works with Amazon Web Services, Azure Key Vault, Redis and Terraform. 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

  • DevOps & Cloud work in your project

Example prompts

  • “/atmos-stores”

Requirements

  • A credential in ARTIFACTORY_ACCESS_TOKEN
  • A credential in JFROG_ACCESS_TOKEN

Workflow steps

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

  1. Configure the store in atmos.yaml
  2. Set up hooks on VPC to write outputs after apply
  3. Read stored values in EKS component

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

    No scripts in the folder and no shell commands in SKILL.md (its code samples are yaml and bash).

    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 these keys or tokens, usually read from environment variables:

    • ARTIFACTORY_ACCESS_TOKEN
    • JFROG_ACCESS_TOKEN
    • GOOGLE_APPLICATION_CREDENTIALS

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

Context cost

Atmos Stores loads about 4.2k tokens when it runs, and up to ~9.2k if it reads all its reference files. Until then it costs about 57 tokens; SKILL.md has 1,244 words of instructions outside code blocks.

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

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). 1,244 words, ~4,208 tokens.

Download SKILL.mdSave it as .claude/skills/atmos-stores/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
atmos-stores
description
Store backends: AWS SSM, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Redis, Artifactory configuration, hooks integration, cross-component data sharing, atmos store CLI CRUD, type: store workflow step
metadata.copyright
Copyright Cloud Posse, LLC 2026
metadata.version
1.0.0
metadata.category
templating-data

Atmos External Stores

Stores are external key-value backends configured in atmos.yaml that enable components to share data outside of Terraform state. Atmos supports store providers including AWS SSM Parameter Store, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Redis, and JFrog Artifactory.

When to Use Stores

Use stores when you need to:

  • Share data between components that is not managed by Terraform
  • Access configuration from external systems (SSM, Azure Key Vault, Redis)
  • Integrate with CI/CD pipelines that write to parameter stores
  • Store and retrieve Terraform outputs via hooks for faster cross-component reads
  • Share state across accounts, regions, or cloud providers

For Terraform-managed outputs, prefer !terraform.state (fastest) or !terraform.output. Use stores for external data or when you need a write-back mechanism via hooks.

Configuring Stores in atmos.yaml

All stores are declared under the top-level stores: key in atmos.yaml. Each store has a unique name, a kind, and provider-specific options. The legacy type field remains supported for compatibility, but kind is canonical:

yaml
# atmos.yaml
stores:
  prod/ssm:
    kind: aws/ssm
    options:
      region: us-east-1

  prod/asm:
    kind: aws/asm
    options:
      region: us-east-1

  prod/azure:
    kind: azure/keyvault
    options:
      vault_url: "https://my-keyvault.vault.azure.net/"

  prod/gcp:
    kind: gcp/secretmanager
    options:
      project_id: my-project

  cache:
    type: redis
    options:
      url: "redis://localhost:6379"

  artifacts:
    type: artifactory
    options:
      url: https://artifactory.example.com
      repo_name: my-repo
Store Naming Convention

Store names follow the pattern <environment>/<type> by convention:

  • prod/ssm -- Production SSM Parameter Store
  • dev/secrets -- Development secrets
  • shared/config -- Shared configuration store

These names are referenced in !store function calls and hook configurations.

Common Options (All Providers)

All store providers support these optional fields:

  • prefix -- String prepended to all keys (scopes the store namespace)
  • stack_delimiter -- Character used to split stack names into key path segments (defaults vary by provider)
Identity-Based Authentication

Stores that support identity-based authentication accept an identity field at the store level (not inside options). This connects the store to an Atmos auth identity for credential resolution:

yaml
stores:
  prod/ssm:
    kind: aws/ssm
    identity: prod-aws  # References an identity defined in the auth section
    options:
      region: us-east-1

Identity-based auth is supported by AWS SSM, AWS Secrets Manager, Azure Key Vault, and Google Secret Manager. It is not supported by Redis or Artifactory (a warning is logged if configured).

Store Provider Configuration

AWS SSM Parameter Store
yaml
stores:
  prod/ssm:
    kind: aws/ssm
    options:
      region: us-east-1           # Required
      prefix: myapp               # Optional: prepended to all key paths
      stack_delimiter: "/"         # Optional: default is "-"
      read_role_arn: arn:aws:iam::123456789012:role/SSMReader   # Optional: cross-account read
      write_role_arn: arn:aws:iam::123456789012:role/SSMWriter  # Optional: cross-account write

Authentication uses the AWS default credential chain (environment variables, shared credentials, instance profile). Use read_role_arn/write_role_arn for cross-account access via STS AssumeRole.

Key format: /<prefix>/<stack-parts>/<component-parts>/<key> (segments joined by /).

AWS Secrets Manager
yaml
stores:
  prod/asm:
    kind: aws/asm
    options:
      region: us-east-1
      prefix: myapp
      stack_delimiter: "/"

Use secret: true with kind: aws/asm for declared secrets managed through atmos secret and !secret.

Azure Key Vault
yaml
stores:
  prod/azure:
    kind: azure/keyvault
    options:
      vault_url: "https://my-keyvault.vault.azure.net/"  # Required
      prefix: myapp               # Optional
      stack_delimiter: "-"         # Optional: default is "-"
      labels:                      # Optional: applied as Azure Key Vault secret tags
        managed-by: atmos
      expires: 90d                 # Optional: 90d, 2160h, 2027-01-01, or RFC 3339

Authentication uses the Azure Default Credential chain (environment variables, managed identity, Azure CLI). Secret names are normalized to comply with Azure Key Vault restrictions: only alphanumeric characters and hyphens are allowed.

Key format: <prefix>-<stack-parts>-<component-parts>-<key> (segments joined by -, non-alphanumeric characters replaced with -).

Google Secret Manager
yaml
stores:
  prod/gcp:
    kind: gcp/secretmanager
    options:
      project_id: my-project     # Required
      prefix: myapp              # Optional
      stack_delimiter: "_"       # Optional: default is "-"
      credentials: '{"type":"service_account",...}'  # Optional: inline JSON credentials
      locations:                 # Optional: replication locations
        - us-east1
        - us-west1

Authentication uses the GCP default credential chain or the GOOGLE_APPLICATION_CREDENTIALS environment variable. Provide credentials inline for service account JSON. If locations is omitted, automatic replication is used.

Key format: <prefix>_<stack-parts>_<component-parts>_<key> (segments joined by _, slashes replaced with _).

Redis
yaml
stores:
  cache:
    type: redis
    options:
      url: "redis://localhost:6379"  # Required (or set ATMOS_REDIS_URL env var)
      prefix: myapp                  # Optional
      stack_delimiter: "/"           # Optional: default is "/"

The url supports Redis URL format including authentication: redis://:password@host:port/db. If url is not set, the ATMOS_REDIS_URL environment variable is used.

Key format: <prefix>/<stack-parts>/<component-parts>/<key> (segments joined by /). For !store.get, prefix is joined with : separator.

Artifactory
yaml
stores:
  artifacts:
    type: artifactory
    options:
      url: https://artifactory.example.com   # Required
      repo_name: my-repo                      # Required
      access_token: !env ARTIFACTORY_ACCESS_TOKEN  # Optional (see auth below)
      prefix: myapp                           # Optional
      stack_delimiter: "/"                    # Optional: default is "/"

Authentication uses access_token from options, or falls back to ARTIFACTORY_ACCESS_TOKEN or JFROG_ACCESS_TOKEN environment variables. Set token to "anonymous" for unauthenticated access.

Create a Generic repository type in JFrog Artifactory. Atmos stores data as JSON files, so no specific package type is required.

Key format: <repo_name>/<prefix>/<stack-parts>/<component-parts>/<key> (segments joined by /).

Reading from Stores with YAML Functions

!store -- Component-Aware Access

Reads values following the Atmos stack/component/key naming convention. The store constructs the full key path from the stack name, component name, and key:

yaml
vars:
  # Three-argument form: store + component + key (current stack implied)
  vpc_id: !store prod/ssm vpc vpc_id

  # Four-argument form: store + stack + component + key
  vpc_id: !store prod/ssm plat-ue2-prod vpc vpc_id

  # Dynamic stack reference using Go templates
  vpc_id: !store prod/ssm {{ .stack }} vpc vpc_id

  # With default value for cold-start scenarios
  api_key: !store prod/ssm config api_key | default "not-set"

  # With YQ query to extract nested data
  db_host: !store prod/ssm database config | query .host

  # Extract from list
  first_subnet: !store prod/ssm vpc subnet_ids | query .[0]

Dynamic stack construction using printf:

yaml
vars:
  # Cross-tenant reference
  vpc_id: !store prod/ssm {{ printf "net-%s-%s" .vars.environment .vars.stage }} vpc vpc_id

  # Full context-based stack name
  config: !store prod/ssm {{ printf "%s-%s-%s" .vars.tenant .vars.environment .vars.stage }} config settings
!store.get -- Arbitrary Key Access

Reads arbitrary keys directly from a store without the stack/component/key convention. Use this for values written by external systems or global configuration:

yaml
vars:
  # Direct key access
  db_password: !store.get prod/ssm /myapp/prod/db/password

  # With default value
  feature_flag: !store.get prod/ssm /features/new-feature | default "disabled"

  # With YQ query
  api_key: !store.get cache app-config | query .api.key

  # Dynamic key with templates
  config: !store.get cache "config-{{ .vars.region }}"

Key differences between !store and !store.get:

Feature!store!store.get
Key constructionBuilds from stack/component/keyUses exact key as provided
Use caseAtmos-managed component outputsExternal systems, global config
Typical patternprefix/stack/component/keyAny format the store supports
atmos.Store -- Go Template Access

Read from stores within Go template expressions:

yaml
vars:
  vpc_id: '{{ atmos.Store "prod/ssm" .stack "vpc" "vpc_id" }}'
  config: !template '{{ (atmos.Store "cache" .stack "config" "config_map").defaults | toJSON }}'

Writing to Stores with Hooks

Hooks write Terraform outputs to stores after atmos terraform apply or atmos terraform deploy. Configure hooks at any level (global, terraform-level, component-level) and Atmos deep-merges them:

yaml
# Full hook definition on a component
components:
  terraform:
    vpc:
      hooks:
        store-outputs:
          events:
            - after-terraform-apply
          command: store
          name: prod/ssm
          outputs:
            vpc_id: .vpc_id
            private_subnet_ids: .private_subnet_ids
            public_subnet_ids: .public_subnet_ids

Output values starting with . reference Terraform output names. The hook retrieves these from the Terraform state and writes them to the configured store.

DRY Hook Configuration (Layered)

Split hook configuration across inheritance levels to avoid repetition:

yaml
# stacks/catalog/vpc/_defaults.yaml -- global level
hooks:
  store-outputs:
    events:
      - after-terraform-apply
    command: store

# stacks/orgs/acme/plat/prod/_defaults.yaml -- account level
terraform:
  hooks:
    store-outputs:
      name: prod/ssm

# stacks/orgs/acme/plat/prod/us-east-2.yaml -- component level
components:
  terraform:
    vpc:
      hooks:
        store-outputs:
          outputs:
            vpc_id: .vpc_id

Atmos merges these into a complete hook definition at resolution time.

Show full SKILL.md (546 more words)Show less

Write to Stores with the CLI or a Workflow Step

For raw CRUD access to any configured store, use the atmos store CLI command family or the type: store workflow step. This access works for any store, not only Terraform outputs. Neither method requires a declaration. Both operate directly on any store configured under stores:, by name.

shell
# CLI: set, get, delete, list -- scope to a stack and component, or omit for a global value
atmos store set app-metadata image_tag sha256:abc123 --stack=prod --component=ecs-service
atmos store get app-metadata image_tag --stack=prod --component=ecs-service
atmos store list
atmos store list app-metadata --stack=prod --component=ecs-service

Passing a store name to atmos store list lists the key/value pairs stored under a scope (instead of the configured backends themselves), for backends that support key enumeration. Most backends support it. 1Password and the default system keychain backend do not, because their underlying APIs do not support enumeration. Check the Listable column in a bare atmos store list before relying on it for a given store. Values are masked the same way atmos store get masks a single value.

yaml
# Workflow, custom-command, or hook step: write a value, for example an image tag from a build step
- name: record-tag
  type: store
  action: write
  with:
    store: app-metadata
    key: image_tag
    value: "{{ .steps.push.metadata.digest }}"
    stack: prod
    component: ecs-service

Atmos allows you to write to a secret: true store this way, for example to write a generated password. But this write skips the atmos secret declaration and scope system. When a value must be tracked as a formal secret, use secrets.vars and atmos secret set instead. See the atmos-secrets skill for that system. See the atmos-steps skill and the /workflows/steps/type/store docs for the step type.

Cross-Account and Cross-Region Access

AWS Cross-Account via Role Assumption
yaml
stores:
  prod/ssm:
    kind: aws/ssm
    options:
      region: us-east-1
      read_role_arn: arn:aws:iam::123456789012:role/SSMReader
      write_role_arn: arn:aws:iam::123456789012:role/SSMWriter

Atmos uses STS AssumeRole to obtain temporary credentials for the target account. Separate read and write roles allow least-privilege access.

Multi-Region Configuration

Define separate stores per region:

yaml
stores:
  prod-us/ssm:
    kind: aws/ssm
    options:
      region: us-east-1

  prod-eu/ssm:
    kind: aws/ssm
    options:
      region: eu-west-1

Reference the appropriate store in each stack's configuration.

End-to-End Example: VPC to EKS

  1. Configure the store in atmos.yaml:
yaml
stores:
  prod/ssm:
    kind: aws/ssm
    options:
      region: us-east-1
  1. Set up hooks on VPC to write outputs after apply:
yaml
# stacks/catalog/vpc/_defaults.yaml
hooks:
  store-outputs:
    events:
      - after-terraform-apply
    command: store
    name: prod/ssm
    outputs:
      vpc_id: .vpc_id
      private_subnet_ids: .private_subnet_ids
  1. Read stored values in EKS component:
yaml
# stacks/prod/us-east-1.yaml
components:
  terraform:
    eks:
      vars:
        vpc_id: !store prod/ssm vpc vpc_id
        subnet_ids: !store prod/ssm vpc private_subnet_ids

Security Best Practices

  • Secrets exposure: !store, !store.get, and atmos.Store read values in cleartext and reject stores marked secret: true. Use secret: true plus !secret and atmos secret for sensitive values.
  • Least privilege: Use read_role_arn/write_role_arn to separate read and write permissions. Grant only the permissions each operation needs.
  • Environment variables for tokens: Never hardcode access tokens. Use !env or environment variables (ARTIFACTORY_ACCESS_TOKEN, JFROG_ACCESS_TOKEN, ATMOS_REDIS_URL).
  • Cold-start handling: Always provide | default values for store lookups that may reference unprovisioned components.
  • DR implications: Be cautious with cross-region store references. If a region goes down, stores in that region become unavailable.
  • Permission scoping: When using atmos describe affected with !store references, Atmos needs read access to all referenced stores. Limited permissions (e.g., dev-only) will cause failures when referencing production stores.

Troubleshooting

ProblemCauseSolution
store type not foundInvalid kind/type in store configUse one of: aws/ssm, aws/asm, azure/keyvault, gcp/secretmanager, redis, artifactory
region is requiredMissing region for SSM storeAdd region to store options
vault_url is requiredMissing vault_url for AzureAdd vault_url to store options
project_id is requiredMissing project_id for GCPAdd project_id to store options
failed to parse redis urlInvalid Redis URL formatUse format redis://:password@host:port/db
access_token must be setMissing Artifactory tokenSet access_token in options or ARTIFACTORY_ACCESS_TOKEN env var
Key not found errorsComponent not yet provisionedAdd a default fallback value to the !store call
Permission deniedInsufficient IAM/RBAC permissionsCheck role ARNs, vault policies, or service account permissions
Identity warning loggedIdentity set on unsupported providerRemove identity from Redis and Artifactory stores

Reference

For detailed provider configuration, authentication patterns, and advanced hook integration, see references/store-providers.md.

© 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-stores of cloudposse/atmos.

  • SKILL.md
  • references/store-providers.md

Open the folder on GitHubat commit 36726ae

Compare with similar skills

Atmos Stores 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 Stores compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Atmos Stores this skillcloudposse/atmos1.4k—~4.2kAutomated safety check: PassApache-2.0
Heroku To AWSaws/agent-toolkit-for-aws2.8k—~7.2kAutomated safety check: PassApache-2.0
AWS Cloud Patternsrohitg00/awesome-claude-code-toolkit2.7k—~1.1kAutomated safety check: PassApache-2.0
Review Docshashicorp/terraform-provider-aws11k—~1.3kAutomated safety check: PassMPL-2.0
Senior DevOps Toolkitmaslennikov-ig/claude-code-orchestrator-kit2606 repos~1.1kAutomated safety check: NotesCustom licence
Terravision Cloud Diagramspatrickchugh/terravision1.6k—~5.6kAutomated safety check: NotesAGPL-3.0-only

Similar skills

  • Heroku To AWS

    aws/agent-toolkit-for-aws

    Official

    Migrate workloads from Heroku to AWS. An agent skill from aws/agent-toolkit-for-aws.

    2.8k GitHub stars~7.2k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • AWS Cloud Patterns

    rohitg00/awesome-claude-code-toolkit

    AWS cloud patterns for Lambda, ECS, S3, DynamoDB, and Infrastructure as Code with CDK/Terraform

    2.7k GitHub stars~1.1k tokensUpdated 4 mo ago
    DevOps & CloudAuto-check passed
  • Review Docs

    hashicorp/terraform-provider-aws

    Official

    Review a Terraform AWS Provider PR's end-user documentation (website/docs//.markdown): whether docs are needed, description openings, argument/attribute style, section structure, tags wording, code…

    11k GitHub stars~1.3k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Senior DevOps Toolkit

    maslennikov-ig/claude-code-orchestrator-kit

    Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure). Includes pipeline setup…

    260 GitHub starsUsed in 6 repos~1.1k tokens
    DevOps & CloudAuto-check: notes
  • Terravision Cloud Diagrams

    patrickchugh/terravision

    Draw cloud architecture diagrams for AWS, Azure or GCP with the official provider icon sets, using TerraVision.

    1.6k GitHub stars~5.6k tokensUpdated 2 days ago
    DevOps & CloudAuto-check: notes
  • Review Helpers

    hashicorp/terraform-provider-aws

    Official

    Review Terraform AWS Provider helper code: finders, status functions, waiters, sweepers, data sources, and list resources.

    11k GitHub stars~978 tokensUpdated yesterday
    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

Questions about Atmos Stores

What does Atmos Stores do?

Store backends: AWS SSM, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Redis, Artifactory configuration, hooks integration, cross-component data sharing, atmos store CLI CRUD, type…. Atmos Stores is an agent skill from cloudposse/atmos.

When should I use Atmos Stores?

Atmos Stores fits situations like: devOps & Cloud work in your project.

How do I install Atmos Stores in Claude Code?

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

How do I install Atmos Stores in Codex?

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

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

What does Atmos Stores need to run?

Going by SKILL.md and its folder, Atmos Stores needs credentials named ARTIFACTORY_ACCESS_TOKEN, JFROG_ACCESS_TOKEN and GOOGLE_APPLICATION_CREDENTIALS. Our summary lists: A credential in ARTIFACTORY_ACCESS_TOKEN; A credential in JFROG_ACCESS_TOKEN.

Does Atmos Stores 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 Stores 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 Stores use?

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

About 4.2k tokens (SKILL.md is roughly 17k 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 5k tokens, read only when the agent opens those files.

What are the alternatives to Atmos Stores?

Skills that share tags, products or a category with Atmos Stores: Heroku To AWS (aws/agent-toolkit-for-aws, 2.8k stars), AWS Cloud Patterns (rohitg00/awesome-claude-code-toolkit, 2.7k stars), Review Docs (hashicorp/terraform-provider-aws, 11k stars) and Senior DevOps Toolkit (maslennikov-ig/claude-code-orchestrator-kit, 260 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Atmos Stores?

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.