arn-infra-env

Arness Infra Env

Configure and manage infrastructure environments (dev, staging, production) with provider-specific isolation strategies, environment-specific variable overrides, resource sizing, and promotion rules. This skill generates environment-specific IaC configurations and updates the environment promotion pipeline.

This skill is expertise-adaptive: beginner users get simplified environment setups with opinionated defaults, while expert users have full control over isolation strategies and promotion configurations.

Prerequisites

Read ## Arness from the project's CLAUDE.md. If no ## Arness section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run /arn-infra-wizard to get started — it will set everything up automatically." Do not proceed without it.

Check the Deferred field. If Deferred: yes, inform the user: "Infrastructure is in deferred mode. Environment management is not available until infrastructure is fully configured. Run /arn-infra-assess to un-defer." Stop.

Extract:

• Experience level -- derived from user profile. Read ~/.arness/user-profile.yaml (or .claude/arness-profile.local.md if it exists — project override takes precedence). Apply the experience derivation mapping from ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md. If no profile exists, check for legacy Experience level in ## Arness as fallback.
• Providers -- cloud providers in use
• Providers config -- path to providers.md for per-provider details
• Default IaC tool -- the default IaC tool
• Environments -- current environment list in promotion order
• Environments config -- path to environments.md

Workflow

Step 1: Read Current Environment Configuration

Read the environment configuration:

Read <environments-config-path>

Extract the current state:

• Promotion pipeline order
• Per-environment settings (auto-deploy, approval required, last deployed, pending changes)

Read the provider configuration:

Read <providers-config-path>

Extract per-provider scope and IaC tool for environment-specific config generation.

Present current state: "Your current environment pipeline: [env1] --> [env2] --> [env3]

| Environment | Auto-deploy | Approval | Last deployed | |-------------|-------------|----------|---------------| [table of environments]"

Ask (using AskUserQuestion):

"What would you like to do?"

Options:

1. Full environment setup -- Run through all environment tasks sequentially
2. Specific task -- Choose a specific environment task

If Full environment setup: proceed through Steps 2-5 sequentially, pausing for user confirmation at each decision point.

If Specific task:

Ask (using AskUserQuestion):

"Which task?"

Options:

1. Add environment -- Add a new environment to the pipeline
2. Configure environment -- Set up isolation, variables, and sizing
3. Configure promotion -- Set up or update promotion rules between environments
4. Generate configs -- Generate environment-specific IaC configurations

Route each specific task to its corresponding step: Add environment maps to Step 2, Configure environment maps to Step 3, Configure promotion maps to Step 5, Generate configs maps to Step 4.

Step 2: Environment Isolation Strategy

Read the local override or plugin default for environment-patterns.md.

For each provider, recommend an isolation strategy based on experience level:

Expert: Present all isolation options with trade-offs and let the user choose:

Ask (using AskUserQuestion):

"For [provider], choose your isolation strategy:"

Options:

1. Account/project separation -- Strongest isolation, separate billing, higher overhead
2. VPC/network separation -- Good isolation within same account, shared billing
3. Namespace separation -- Lightweight, shared resources, weakest isolation
4. Resource naming -- Minimal isolation, environments share everything

Intermediate: Present the recommended option with a brief alternative: "For [provider], I recommend [strategy] because [rationale]. An alternative would be [other option] which trades [trade-off]."

Beginner: Make the recommendation directly: "For [provider], I'll use [simplest appropriate strategy]. This gives you separate environments without extra complexity."

Step 3: Environment-Specific Variables and Sizing

For each environment, configure:

Variable overrides:

• Instance sizes (e.g., t3.micro for dev, t3.medium for staging, t3.large for prod)
• Replica counts (e.g., 1 for dev, 2 for staging, 3 for prod)
• Database tiers (e.g., db.t3.micro for dev, db.r6g.large for prod)
• Feature flags (e.g., debug mode on for dev, off for prod)
• Domain names and URLs per environment
• Log levels and retention periods

Resource sizing guidance per experience level:

Expert: Ask for specific resource specifications per environment.

Intermediate: Suggest a sizing matrix and ask for approval: "Here's a recommended sizing matrix: | Resource | Dev | Staging | Prod | |----------|-----|---------|------| | Compute | [small] | [medium] | [large] | | Database | [small] | [medium] | [large] | | Replicas | 1 | 2 | 3 | Adjust as needed."

Beginner: Apply defaults automatically: "I'll use small resources for dev, medium for staging, and appropriately sized resources for production. This keeps costs low during development."

Step 4: Generate Environment-Specific IaC Configurations

Based on the IaC tool, generate environment-specific configuration files:

| IaC Tool | Config Format | Example | |----------|--------------|---------| | OpenTofu / Terraform | environments/<env>.tfvars | instance_type = "t3.small" | | Pulumi | Pulumi.<env>.yaml stack config | config: app:instanceType: t3.small | | CDK | Environment props in cdk.json or separate env file | { "env": { "account": "...", "region": "..." } } | | Bicep | environments/<env>.parameters.json | { "parameters": { "instanceType": { "value": "..." } } } | | Kubernetes | environments/<env>/kustomization.yaml or values-<env>.yaml | Kustomize overlays or Helm value overrides | | PaaS (none) | Platform-native env config | Environment-specific sections in fly.toml, vercel.json |

Invoke the arn-infra-specialist agent via the Task tool, passing the model from .arness/agent-models/infra.md as the model parameter (see plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

--- ENVIRONMENT CONTEXT --- Environments: [list in promotion order] [For each environment:] Environment: [name] Isolation strategy: [strategy] Variable overrides: [key-value pairs] Resource sizing: [specifications] --- END ENVIRONMENT CONTEXT ---

--- PROVIDER CONFIGURATION --- [For each provider:] Provider: [name] IaC tool: [tool] Scope: [components] --- END PROVIDER CONFIGURATION ---

--- INFRASTRUCTURE CONFIG --- Experience level: [derived from user profile] --- END INFRASTRUCTURE CONFIG ---

--- INSTRUCTIONS --- Generate environment-specific configuration files for each environment and provider combination.

For each environment:

1. Generate the appropriate config file format for the IaC tool
2. Include all variable overrides (instance sizes, replicas, domains, feature flags)
3. Include environment-specific tags/labels for resource identification
4. Reference shared modules/resources -- environments differ only in configuration values

Follow these rules:

• Adapt comment verbosity and configuration complexity to the experience level
• Never hardcode secrets in config files -- use variable references or secret manager
• Include comments explaining environment-specific choices
• For the production environment, include higher-availability settings (multi-AZ, auto-scaling)
• For development, optimiz