arn-infra-define

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 level and provider configuration, determine what to generate.

Beginner path (Experience level: beginner): Generate platform-native configurations instead of IaC. Load the PaaS config patterns:

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

Map the user's provider to the appropriate config format:

• Fly.io --> fly.toml
• Railway --> railway.json
• Render --> render.yaml
• Vercel --> vercel.json
• Netlify --> netlify.toml

If the beginner has chosen an IaC-required provider (AWS, GCP, Azure), suggest simpler alternatives or generate simplified IaC with extensive comments.

Intermediate / Expert path: Generate full IaC code. Load the appropriate tool-specific reference:

| IaC Tool | Reference | |----------|-----------| | OpenTofu / Terraform | Read the local override or plugin default for opentofu-patterns.md. | | Pulumi | Read the local override or plugin default for pulumi-patterns.md. | | CDK | Read the local override or plugin default for cdk-patterns.md. | | Bicep | Read the local override or plugin default for bicep-patterns.md. | | Kubernetes (kubectl/Helm) | Read the local override or plugin default for kubernetes-patterns.md. |

For multi-provider setups:

Ask (using AskUserQuestion):

"You have multiple providers configured: [list]. Which provider(s) would you like to generate IaC for now?"

Options:

1. All -- Generate per-provider IaC in separate directories
2. Specific provider(s) -- Choose which providers to generate for

Step 5: Invoke Specialist Agent for IaC Generation

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:

--- APPLICATION CONTEXT --- [Application architecture from Step 3, or triage brief content from Step 2] Services: [list of services with roles] Databases: [required databases and their types] Caches: [required caching layers] External services: [third-party integrations, APIs] Traffic patterns: [expected request volume, scaling requirements] --- END APPLICATION CONTEXT ---

--- PROVIDER CONFIGURATION --- [For each provider being generated:] Provider: [name] Scope: [which components this provider handles] IaC tool: [tool name] [Tool-specific patterns from the loaded reference file] --- END PROVIDER CONFIGURATION ---

--- ENVIRONMENT CONFIGURATION --- Environments: [from environments config] Promotion pipeline: [env1 --> env2 --> env3] --- END ENVIRONMENT CONFIGURATION ---

--- INFRA