/arn-infra-pipeline

name: arn-infra-pipeline
description: >-
  This skill should be used when the user says "infra pipeline", "arn infra pipeline",
  "create CI/CD pipeline", "set up deployment pipeline", "generate pipeline",
  "infra CI/CD", "deployment pipeline", "setup cicd", "generate github actions",
  "generate gitlab ci", "generate bitbucket pipeline", "infrastructure pipeline", "pipeline setup",
  "create deployment workflow", "cicd for infrastructure", "infra deployment pipeline",
  "set up infrastructure CI/CD", "arn-infra-pipeline", or wants to generate
  infrastructure-specific CI/CD pipelines with SOC 2 alignment, OIDC authentication,
  and environment-aware deployment stages.
version: 1.0.0

Arness Infra Pipeline

Generate infrastructure-specific CI/CD pipelines (separate from application CI/CD) with SOC 2 alignment. This skill produces four pipeline jobs: PR validation, staging deployment, production promotion, and scheduled cleanup. It detects existing CI configurations from arn-spark and extends rather than replaces them.

The generated pipelines implement security best practices: OIDC authentication for cloud providers (no static credentials), separate IAM roles per environment, plan-as-artifact audit trails, and branch protection enforcement.

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. CI/CD pipeline setup 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.
• **Platform** -- code hosting platform (github, bitbucket, none)
• **Providers** -- cloud providers in use
• **Providers config** -- path to `providers.md` for per-provider IaC tool details
• **Default IaC tool** -- the default IaC tool
• **Environments** -- environment names in promotion order
• **Environments config** -- path to `environments.md` for promotion rules
• **Tooling manifest** -- path to `tooling-manifest.json` for available tools
• **Validation ceiling** -- maximum validation level
• **Issue tracker** -- for scheduled cleanup job notifications

Extract the **CI/CD platform** field from `## Arness` config. If not present, auto-detect by scanning for `.github/workflows/`, `.gitlab-ci.yml`, or `bitbucket-pipelines.yml`.

---

Workflow

Step 1: Read Provider, Environment, and Tooling Configuration

Read the provider configuration:

Read <providers-config-path>

For each provider, extract:

• Provider name, scope, IaC tool
• Status (skip providers with `Status: inactive`)

Read the environment configuration:

Read <environments-config-path>

Extract:

• Promotion pipeline order (e.g., dev --> staging --> prod)
• Auto-deploy flags per environment
• Approval requirements per environment

Read the tooling manifest:

Read <tooling-manifest-path>

Check for available CI/CD-relevant tools:

• IaC CLIs (tofu, terraform, pulumi, cdk, bicep)
• Security scanners (checkov, trivy)
• Cost estimation (infracost)

---

Step 2: Detect Existing CI/CD

Scan for existing pipeline configurations:

Glob .github/workflows/*.yml
Glob .github/workflows/*.yaml
Glob .gitlab-ci.yml
Glob bitbucket-pipelines.yml

**If existing CI/CD is found:** Read and understand the existing pipeline structure. Present findings: "I found existing CI/CD pipelines: [list files]. Infrastructure pipelines will be generated as separate workflow files to extend, not replace, your existing setup."

**If no existing CI/CD is found:** Note: "No existing CI/CD detected. Generating infrastructure pipelines from scratch."

---

Step 3: Determine Pipeline Platform and Load Patterns

Based on the `CI/CD platform` from `## Arness` config (auto-detected from CI config files, independent of the code hosting Platform):

| CI/CD Platform | Reference | |----------------|-----------| | `github-actions` | Read the local override or plugin default for `github-actions-patterns.md`. | | `gitlab-ci` | Read the local override or plugin default for `gitlab-ci-patterns.md`. | | `bitbucket-pipelines` | Read the local override or plugin default for `bitbucket-pipelines-patterns.md`. | | `none` | Ask the user which CI/CD platform to target. If no preference, recommend GitHub Actions for GitHub-hosted repos, Bitbucket Pipelines for Bitbucket-hosted repos, or GitLab CI for self-hosted/GitLab-hosted repos. |

Load the security checklist:

> Read the local override or plugin default for `pipeline-security-checklist.md`.

---

Step 4: Invoke Pipeline Builder Agent

Invoke the `arn-infra-pipeline-builder` 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:

--- PLATFORM CONTEXT --- CI/CD platform: [github-actions | gitlab-ci | bitbucket-pipelines] Existing CI/CD files: [list of detected files, or "none"] --- END PLATFORM CONTEXT ---

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

--- ENVIRONMENT CONFIGURATION --- Environments: [list in promotion order] Promotion pipeline: [env1 --> env2 --> env3] [For each environment:] Environment: [name] Auto-de