/arn-infra-env

name: arn-infra-env
description: >-
  This skill should be used when the user says "manage environments", "arn infra env",
  "infra env", "environment setup", "configure environments", "set up staging",
  "set up production", "environment management", "create environment",
  "environment promotion", "promote to staging", "promote to production",
  "environment isolation", "configure dev staging prod",
  "environment-specific config", "tfvars per environment", "arn-infra-env",
  or wants to configure, create, or manage infrastructure environments
  (dev/staging/production) with isolation strategies, variable overrides,
  and promotion rules.
version: 1.0.0

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] | |