(github actions) generated latest snippets

Author: milldr

examples/snippets/.claude/skills/account-map-migration/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: account-map-migration
+description:
+  Use when fixing legacy account-map component references. Covers migration from dynamic account-map lookups to static
+  account_map variable with Atmos Auth.
+---
+
+# Account Map Migration
+
+This implementation is migrating away from the `account-map` component to use Atmos Auth for authentication. Instead of
+dynamically looking up account IDs via the account-map component, we use a static `account_map` variable defined in
+`stacks/orgs/acme/_defaults.yaml`.
+
+## Key Patterns
+
+- **`account_map_enabled: false`** - Disables the legacy account-map component lookup
+- **`account_map` variable** - Static map containing `full_account_map` (account names to IDs),
+  `iam_role_arn_templates`, and account name references
+- **Dummy `iam_roles` module** in `providers.tf` - Satisfies legacy module dependencies that expect this output
+
+## When You Encounter Legacy References
+
+You may still see references to `account_map` in remote-state configurations that need to be fixed. When creating new
+components or fixing existing ones, use the pattern from recently updated components (e.g., `vpc`, `ecr`) that use the
+static `account_map` variable instead of the account-map component.
+
+## Reference Implementation
+
+See `components/terraform/vpc/providers.tf` for the current pattern with:
+
+- `account_map_enabled = false`
+- Static `account_map` variable usage
+- Dummy `iam_roles` module for compatibility

examples/snippets/.claude/skills/atmos-authentication/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: atmos-authentication
+description:
+  Use when authenticating with AWS via Atmos. Covers ATMOS_PROFILE setup, SSO login, and how Atmos automatically assumes
+  the correct identity per stack.
+---
+
+# Atmos Authentication
+
+Atmos Auth handles AWS authentication automatically based on your profile and the target stack.
+
+## Quick Start
+
+```bash
+# Set your profile (required for all atmos commands)
+export ATMOS_PROFILE=devops  # or: developers, managers
+
+# Run commands - Atmos auto-selects the correct identity per stack
+# If not authenticated, this will automatically launch the IDP to sign in
+atmos terraform plan vpc -s plat-use2-dev
+```
+
+## How It Works
+
+1. **Set your profile**: `export ATMOS_PROFILE=<profile-name>` (or prefix each command)
+2. **Run commands**: Atmos automatically assumes the correct identity for each stack based on the stack name. If you're not authenticated or credentials have expired, Atmos will automatically launch the IDP to sign in.
+
+When you run `atmos terraform plan <component> -s <stack>`, Atmos:
+
+1. Renders all stack config, then determines the default identity for the stack
+2. If there's a single default identity (e.g., `plat-dev/terraform`), it's selected automatically
+3. If multiple identities are marked as default, you'll be prompted to select one
+4. Looks up that identity name in your profile to get the actual credentials
+5. Assumes the configured Permission Set or IAM role
+6. Runs the Terraform command with those credentials
+
+We intentionally set only a single default identity per stack to avoid prompts.
+
+## Identity Configuration
+
+Each stack defines its default identity in its `_defaults.yaml` file:
+
+```yaml
+# stacks/orgs/acme/plat/dev/_defaults.yaml
+auth:
+  identities:
+    plat-dev/terraform:
+      default: true
+```
+
+This is simple YAML configuration - no special Atmos magic. The identity name (`plat-dev/terraform`) is then resolved
+by your profile to determine the actual AWS credentials to use.
+
+## Manual Authentication
+
+You don't need to authenticate separately before running Atmos commands - authentication happens automatically when needed.
+However, if you want to pre-authenticate a session or refresh expired credentials, use:
+
+```bash
+atmos auth login --provider acme-sso  # Triggers browser SSO login
+```
+
+Once authenticated, credentials are cached and subsequent commands work automatically.
+
+## Profiles
+
+Profiles are defined in `profiles/<profile-name>/atmos.yaml`. Each maps identities to Permission Sets:
+
+| Profile      | Core Accounts        | Platform Dev/Sandbox | Platform Staging/Prod |
+| ------------ | -------------------- | -------------------- | --------------------- |
+| `devops`     | TerraformApplyAccess | TerraformApplyAccess | TerraformApplyAccess  |
+| `developers` | TerraformStateAccess | TerraformApplyAccess | TerraformPlanAccess   |
+| `managers`   | TerraformStateAccess | TerraformPlanAccess  | TerraformPlanAccess   |
+
+**Permission Set capabilities:**
+
+- `TerraformApplyAccess` - Full plan and apply
+- `TerraformPlanAccess` - Plan only (no apply)
+- `TerraformStateAccess` - Read state only (for cross-account references)
+
+## Identity Naming Convention
+
+Identities follow the pattern: `<tenant>-<stage>/terraform`
+
+Examples:
+
+- `plat-dev/terraform` - Platform dev account
+- `core-auto/terraform` - Core automation account
+- `plat-prod/terraform` - Platform production account
+
+## Special Cases
+
+**superadmin profile**: IAM user with MFA for breakglass access. Avoid unless SSO is unavailable.
+
+**github profile**: OIDC-based authentication for CI/CD pipelines. Not for interactive use.
+
+## Troubleshooting
+
+If authentication fails:
+
+1. Verify `ATMOS_PROFILE` is set: `echo $ATMOS_PROFILE`
+2. Re-authenticate with the provider: `atmos auth login --provider acme-sso`
+3. Check you have the required Permission Set in AWS IAM Identity Center
+4. Verify the identity exists in `profiles/$ATMOS_PROFILE/atmos.yaml`
+
+## Debugging
+
+Enable debug logging to see detailed output:
+
+```bash
+ATMOS_LOGS_LEVEL=debug atmos terraform plan <component> -s <stack>
+```
+
+Inspect the rendered configuration (final YAML after all imports and merges):
+
+```bash
+atmos describe stacks                            # Describe all stacks (large output)
+atmos describe component <component> -s <stack>  # Describe a single component
+```
+
+The `describe` commands output the fully-resolved YAML configuration, which is useful for:
+
+- Debugging variable values and inheritance
+- Seeing which vars come from catalog vs stack overrides
+- Verifying `!terraform.state` references resolve correctly
+
+Reset local Terraform state and cached configuration to start fresh:
+
+```bash
+atmos terraform clean <component> -s <stack>
+```
+
+This destroys the local `.terraform` directory and any rendered configuration files, useful when:
+
+- Provider versions are out of sync
+- Module cache is corrupted
+- You want to force re-initialization

examples/snippets/.claude/skills/atmos-functions/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: atmos-functions
+description:
+  Use when wiring cross-component dependencies in stack YAML. Covers !terraform.state syntax for passing outputs between
+  components without remote-state lookups.
+---
+
+# Cross-Component Dependencies with Atmos Functions
+
+**Preferred approach: Atmos Functions** - Use Atmos template functions in stack YAML to pass values between components
+at plan/apply time. This avoids Terraform remote state lookups entirely.
+
+## `!terraform.state` Syntax
+
+Two-parameter form (current stack):
+
+```yaml
+!terraform.state <component> <output>
+```
+
+Three-parameter form (specific stack):
+
+```yaml
+!terraform.state <component> <stack> <output>
+```
+
+## Examples
+
+```yaml
+components:
+  terraform:
+    my-component:
+      vars:
+        # Current stack lookups (component output)
+        vpc_id: !terraform.state vpc vpc_id
+        subnet_ids: !terraform.state vpc private_subnet_ids
+
+        # Cross-stack lookup (component stack output)
+        grafana_role_arn: !terraform.state grafana core-use2-auto workspace_iam_role_arn
+
+        # Nested output with YQ expression
+        role_arn: !terraform.state iam-role/my-role plat-use2-dev .role.arn
+```
+
+## Best Practices
+
+- **Define lookups in catalog defaults** - Put `!terraform.state` expressions in
+  `stacks/catalog/<component>/defaults.yaml` rather than in stack files. The function automatically resolves based on
+  the current stack context.
+- **Use current-stack lookups when possible** - Omit the stack parameter to look up components in the same stack, making
+  configs more portable.
+- **Cross-stack lookups for shared resources** - Use the three-parameter form when referencing centralized resources
+  (e.g., Grafana in core-auto from plat accounts).
+
+## Legacy Approach (Being Phased Out)
+
+Some older components still use Cloud Posse's `remote-state` Terraform module with `remote-state.tf` files. This pattern
+is being phased out in favor of Atmos functions. The tfstate backend is in the core-auto account.
+
+When you encounter `remote-state.tf` files, prefer converting them to `!terraform.state` expressions in the catalog.

examples/snippets/.claude/skills/developing-components/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: developing-components
+description:
+  Use when creating new Terraform/OpenTofu components or modifying existing ones. Covers required files, catalog
+  defaults, stack configuration, and naming conventions.
+---
+
+# Developing Components
+
+Components are opinionated Terraform root modules that implement a specific AWS resource with predefined conventions.
+
+## Before Creating a New Component
+
+**Always check for existing components first.** Creating new components adds maintenance burden.
+
+### 1. Check Local Generic Components
+
+Many use cases can be solved by configuring existing generic components via catalog:
+
+- **`iam-role`** - Any IAM role. Create `stacks/catalog/iam-role/my-role.yaml` instead of a new component.
+- **`s3-bucket`** - Any S3 bucket with standard configurations.
+- **`lambda`** - Lambda functions with common patterns.
+
+### 2. Check Cloud Posse Component Library
+
+Browse https://docs.cloudposse.com/components/library/ for pre-built components. Common ones:
+
+- `eks/cluster`, `eks/alb-controller` - Kubernetes
+- `aurora-postgres`, `rds` - Databases
+- `elasticache-redis` - Caching
+- `ecs`, `ecs-service` - Container workloads
+- `cloudwatch-logs`, `sns-topic`, `sqs-queue` - AWS services
+
+To vendor a Cloud Posse component:
+
+```bash
+# Add to component.yaml in the component directory, then:
+atmos vendor pull -c <component-name>
+```
+
+### 3. When to Create a Custom Component
+
+Create a new component when:
+
+- **Tightly coupled resources** - The resources share the same lifecycle and must be created/destroyed together. For
+  example, an application-specific ECS service with its ALB target group, CloudWatch alarms, and autoscaling policies.
+- **Unique to your infrastructure** - The configuration is specific to your organization and wouldn't benefit from Cloud
+  Posse's generic abstractions.
+- **Single account/region deployment** - All resources deploy to one AWS account and region. If resources span accounts
+  or regions, split into separate components.
+
+**Teralithic components** (all-in-one) are appropriate when:
+
+- Resources are always deployed together and never independently
+- Splitting would create artificial boundaries requiring complex cross-component wiring
+- The blast radius is acceptable (all resources affected by any change)
+
+**Avoid** custom components when:
+
+- You're wrapping a single AWS resource (use generic components instead)
+- The resources have different lifecycles (e.g., database vs. application)
+- You might reuse this pattern elsewhere (vendor or create a generic component)
+
+---
+
+## New Component Structure
+
+Every new component requires three parts:
+
+## 1. Root Module (`components/terraform/<component-name>/`)
+
+Required files (copy from an existing component like `ecs`):
+
+- **`context.tf`** - Always identical across all components. Copy from any existing component. Provides Cloud Posse's
+  null-label context for consistent naming.
+- **`providers.tf`** - Standard provider configuration. Copy from an existing component. Includes the
+  `account_map_enabled` variable and dummy `iam_roles` module for compatibility.
+- **`versions.tf`** - OpenTofu/Terraform and provider version constraints
+- **`variables.tf`** - Component-specific input variables
+- **`main.tf`** - Main resource definitions
+- **`outputs.tf`** - Output values
+
+**Note on remote-state.tf**: Avoid creating `remote-state.tf` files for new components. Instead, use Atmos functions
+(`!terraform.state`) in stack YAML to pass values from other components. This keeps components simpler and moves
+cross-component wiring to the stack configuration layer.
+
+## 2. Catalog Defaults (`stacks/catalog/<component-name>/defaults.yaml`)
+
+Define organization-wide default values for the component, including dependency lookups:
+
+```yaml
+components:
+  terraform:
+    <component-name>/defaults:
+      metadata:
+        component: <component-name>
+        type: abstract # Makes this a base configuration, not directly deployable
+      vars:
+        enabled: true
+        name: <component-name>
+        # Static defaults
+        some_setting: "default-value"
+        # Dynamic lookups - resolved at plan time based on current stack
+        vpc_id: !terraform.state vpc vpc_id
+        subnet_ids: !terraform.state vpc private_subnet_ids
+```
+
+## 3. Stack Configuration (`stacks/orgs/acme/<tenant>/<stage>/<region>/<layer>.yaml`)
+
+Import the catalog - often no component block is needed if catalog defaults are complete:
+
+```yaml
+import:
+  - orgs/acme/plat/dev/_defaults
+  - mixins/region/us-east-1
+  - catalog/<component-name>/defaults
+```
+
+If overrides are needed:
+
+```yaml
+import:
+  - catalog/<component-name>/defaults
+
+components:
+  terraform:
+    <component-name>:
+      vars:
+        # Account/region-specific overrides only
+        some_setting: "override-value"
+```
+
+## Naming Conventions
+
+- Use descriptive, specific names that indicate the component's purpose
+- Prefix with the service/platform when specific (e.g., `ecs-adot-collector` not just `adot-collector`)
+- Use slashes for component hierarchies in catalogs (e.g., `iam-role/grafana-cloudwatch-access`,
+  `grafana/datasource/cloudwatch`)
+
+## Stack File Organization
+
+Stack files in `stacks/orgs/acme/` mirror the AWS account structure:
+
+- `orgs/acme/core/` - Core accounts (root, audit, security, identity, network, dns, auto, artifacts)
+- `orgs/acme/plat/` - Platform accounts (sandbox, dev, staging, prod)
+
+Within each stage, organized by region:
+
+- `global-region/` - Global (us-east-1) resources like IAM
+- `us-east-2/` - Regional resources
+
+Regional stack files are typically split by layer:
+
+- `foundation.yaml` - VPC, networking, base infrastructure
+- `platform.yaml` - Shared platform services (ECS clusters, databases)
+- `app.yaml` - Application-specific resources

examples/snippets/.github/workflows/atmos-pro-terraform-apply.yaml

@@ -53,6 +53,8 @@ jobs:
 
       - name: Apply Atmos Component
         uses: cloudposse/github-action-atmos-terraform-apply@v4
+        env:
+          ATMOS_PROFILE: "github"
         with:
           # Atmos Pro args
           component: ${{ inputs.component }}