/arn-infra-define

name: arn-infra-define
description: >-
  This skill should be used when the user says "define infrastructure", "generate IaC",
  "infra define", "arn infra define", "generate terraform", "generate opentofu",
  "generate pulumi", "generate cdk", "generate bicep", "create kubernetes manifests",
  "provision cloud resources", "create IaC", "infrastructure as code", or wants to
  generate infrastructure-as-code in their chosen IaC tool for configured cloud
  provider(s). It produces provider-specific infrastructure code, validates it
  through a multi-level validation ladder, and writes an infrastructure architecture
  spec.
version: 1.0.0

Arness Infra Define

Generate infrastructure-as-code in the user's chosen IaC tool for their configured cloud provider(s). This is the central skill in the Arness Infra pipeline -- it reads the project's infrastructure configuration, resolves the application context, generates per-provider IaC code, validates it through a multi-level validation ladder, and produces an infrastructure architecture specification.

This skill is expertise-adaptive: beginner users receive platform-native configurations (e.g., `fly.toml`, `vercel.json`) instead of full IaC. Intermediate and expert users receive IaC in their chosen tool (OpenTofu, Pulumi, CDK, Bicep, kubectl/Helm).

If a triage implications brief exists (from `arn-infra-triage`), this skill uses it as the primary input for infrastructure decisions, skipping redundant codebase analysis.

Prerequisites

Read the `## Arness` section 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.

Extract:

• **Deferred** -- if `yes`, inform the user that infrastructure is deferred and suggest running `/arn-infra-assess` first
• **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** -- which cloud providers to generate IaC for
• **Providers config** -- path to `providers.md` for per-provider scope and IaC tool overrides
• **Default IaC tool** -- the default IaC tool to use when no per-provider override exists
• **Environments** -- environment names (for environment-specific configurations)
• **Environments config** -- path to `environments.md`
• **Tooling manifest** -- path to `tooling-manifest.json` for tool availability checks
• **Cost threshold** -- monthly budget limit for cost gate warnings
• **Validation ceiling** -- maximum validation level before requiring explicit approval
• **Infra plans directory** -- from `## Arness` config, for locating triage briefs (default: `.arness/infra-plans`)
• **Infra specs directory** -- from `## Arness` config, for writing the INFRA spec (default: `.arness/infra-specs`)

---

Workflow

Step 1: Read Provider and Tooling Configuration

Read the provider configuration:

> Read `<providers-config-path>`

For each provider, extract:

• Provider name and scope (which application components it serves)
• IaC tool override (or use the default)
• Status (active, inactive, migrating)
• Migration notes (if any)

Read the environment configuration:

> Read <environments-config-path>

For each environment, extract: environment name, purpose, promotion order, and environment-specific sizing or feature flags.

Read the tooling manifest:

> Read `<tooling-manifest-path>`

Check tool readiness for each provider's IaC tool:

• Is the IaC binary installed? (e.g., `tofu`, `pulumi`, `cdk`)
• Is the provider CLI installed and authenticated?
• Are validation tools available? (e.g., `checkov`, `trivy`, `infracost`)

**If a required IaC tool is missing:** Warn: "The IaC tool `[tool]` is not installed. Arness Infra cannot generate or validate `[tool]` code without it. Run `/arn-infra-discover` to check and install required tools." Ask whether to continue (generate code that cannot be locally validated) or stop.

---

Step 2: Check for Triage Brief

Check for an existing triage implications brief in the infra plans directory:

Glob <infra-plans-dir>/**/triage-brief*.md
Glob <infra-plans-dir>/**/implications-brief*.md

**If a triage brief exists:** Read the brief. Extract infrastructure implications, resource requirements, and architectural decisions. Present: "I found a triage brief with infrastructure implications. Using it as the primary input for infrastructure generation." Skip Step 3 (application context resolution) -- the triage brief already contains the analyzed requirements.

**If no triage brief exists:** Continue to Step 3 for full application context resolution.

---

Step 3: Resolve Application Context

Resolve the application's architecture, services, and resource requirements. This step is skipped if a triage brief was found in Step 2.

Read the `Project topology` from `## Arness`:

**Monorepo:**

• Read `code-patterns.md` and `architecture.md` from the code patterns directory (path from `## Arness` config)
• Scan for application entry points, services, databases, caches, and external dependencies
• Map application components to infrastructure resources

**Separate repo:**

• Navigate to `Application path` and read the application's `## Arness` config, patterns, and architecture
• If unreachable, ask the user to describe the application stack manually

**Infra-only:**

• Ask the user to describe: services, databases, caches, networking requirements, expected traffic patterns
• Record the user-provided context for IaC generation

---

Step 4: Determine Generation Strategy

Based on experience