/arn-infra-deploy

name: arn-infra-deploy
description: >-
  This skill should be used when the user says "deploy", "deploy to staging",
  "deploy to production", "promote to production", "infra deploy", "arn infra deploy",
  "deploy infrastructure", "apply infrastructure", "push to prod", "go live",
  "tofu apply", "terraform apply", "pulumi up", "cdk deploy", "fly deploy",
  "deploy to railway", "release to prod", "promote environment", or wants to
  execute a deployment of their infrastructure to a target environment. This skill
  handles environment promotion, CI/CD enforcement, cost gates, safety layers,
  and resource tracking.
version: 1.0.0

Arness Infra Deploy

Execute infrastructure deployment to a target environment with environment promotion enforcement, CI/CD pipeline awareness, cost gates, safety layers, and post-deployment resource tracking. This skill orchestrates the actual apply/deploy step, producing handoff files with secret references and updating the issue lifecycle.

This skill is expertise-adaptive: beginner users deploy via platform CLI commands (`fly deploy`, `railway up`), while intermediate and expert users deploy via IaC tools (`tofu apply`, `pulumi up`). All experience levels receive the same safety protections.

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.

Extract:

• **Deferred** -- if `yes`, inform the user that infrastructure is deferred and suggest running `/arn-infra-assess` first. Stop.
• **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 are configured
• **Providers config** -- path to `providers.md` for per-provider details and IaC tool overrides
• **Default IaC tool** -- the default IaC tool to use when no per-provider override exists
• **Environments** -- environment names in promotion order
• **Environments config** -- path to `environments.md` for promotion pipeline and deployment state
• **Tooling manifest** -- path to `tooling-manifest.json` for tool availability checks
• **Resource manifest** -- path to `active-resources.json` for resource tracking
• **Cost threshold** -- monthly budget limit for cost gate warnings
• **Validation ceiling** -- maximum validation level before requiring explicit approval
• **Platform** -- for issue label management
• **Issue tracker** -- for issue lifecycle transitions
• **Infra specs directory** -- from `## Arness` config, for locating INFRA spec and handoff files (default: `.arness/infra-specs`)

Read the provider configuration:

Read <providers-config-path>

Read the environment configuration:

Read <environments-config-path>

---

Workflow

Step 1: Determine Target Environment and Promotion Validation

Ask the user which environment they want to deploy to (if not already specified in the invocation):

"Which environment would you like to deploy to? [list environments from config in promotion order]"

**Environment promotion enforcement:**

Read the promotion pipeline from `environments.md`. Enforce the following rules:

1. **No skipping stages:** If the promotion pipeline is `dev --> staging --> production`, the user cannot deploy directly to production unless staging has been deployed and verified. Check the `Last deployed` field for each environment in the pipeline.

2. **Refuse direct-to-prod when staging exists:** If the promotion pipeline includes a staging environment and the user requests deployment to production:

• Check if staging has been deployed (has a `Last deployed` timestamp)
• Check if staging has been verified (has `arn-infra-verified` label or `lastVerified` in resource manifest)
• If staging has NOT been deployed or verified: refuse with "Production deployment requires staging to be deployed and verified first. Run `/arn-infra-deploy` targeting staging, then `/arn-infra-verify` to validate it."
• If staging IS verified: proceed with production deployment

3. **First deployment to any environment is allowed:** If no environment in the pipeline has been deployed yet, allow deployment to the first environment in the pipeline (typically dev or staging).

---

Step 2: CI/CD Enforcement

Check whether CI/CD pipelines exist for the target environment.

Scan for pipeline configurations:

• `.github/workflows/` -- GitHub Actions
• `.gitlab-ci.yml` -- GitLab CI
• `bitbucket-pipelines.yml` -- Bitbucket Pipelines

**If pipelines exist AND the target is staging or production:**

Warn: "I detected CI/CD pipelines in this project. For staging and production deployments, CI/CD is the recommended deployment method -- it ensures reproducibility, audit trails, and team visibility."

Ask (using `AskUserQuestion`):

**"How would you like to deploy?"**

Options: 1. **Use CI/CD** -- Trigger the pipeline (I will help you push and monitor) 2. **Deploy locally** -- Proceed with local deployment (not recommended for staging/prod) 3. **Cancel** -- Do not deploy

If the user chooses CI/CD: help them trigger the pipeline (e.g., `git push`, `gh workflow run`) and monitor the deployment. Skip to Step 8 for post-deployment tracking.

If the user chooses local deployment: proceed with a warning logged and continue to Step 3.

**If no pipelines exist OR the target is dev:** Continue to Step 3 without CI/CD enforcement.

---

Step 3: Pre-Deployment Safety Checklist

> Read the local override or plugin default for `deployment-safety-checklist.md`.