/arn-infra-containerize

name: arn-infra-containerize
description: >-
  This skill should be used when the user says "containerize", "dockerize",
  "create dockerfile", "docker setup", "container setup", "arn infra containerize",
  "infra containerize", "generate docker", "docker compose", "compose setup",
  "containerize my app", "docker configuration", "create docker-compose",
  "multi-stage docker", "container config", "dockerize my application",
  "infra docker", "set up containers", or wants to generate Dockerfiles,
  docker-compose configurations, and .dockerignore files for their application
  with security auditing and multi-stage build best practices.
version: 1.0.0

Arness Infra Containerize

Generate production-ready Dockerfiles, docker-compose configurations, and .dockerignore files for the application. This skill produces security-audited, multi-stage container configurations adapted to the application's technology stack and topology.

This skill reads the application context (codebase patterns, architecture, technology stack) based on the project topology, invokes the `arn-infra-specialist` agent for container configuration generation, and the `arn-infra-security-auditor` agent for security review. All generated files are presented for user approval before being written.

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. Containerization is not available until infrastructure is fully configured. Run `/arn-infra-assess` to un-defer." Stop.

Extract:

• **Project topology** -- how to resolve the application project (monorepo, separate-repo, infra-only)
• **Application path** -- path to the application project root
• **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** -- informs container registry selection and platform-specific optimizations
• **Tooling manifest** -- path to check for Docker/container tools availability

Workflow

Step 1: Resolve Application Context

Resolve the application project based on topology to understand the technology stack, services, and dependencies.

**Monorepo (`Application path: .`):**

• Read codebase patterns from the local code-patterns directory (path from `## Arness` config)
• Read `architecture.md` for technology stack, services, and dependencies
• Scan the source tree for: `package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml`, `*.csproj`, `Gemfile`
• Identify application entry points, build commands, and runtime requirements

**Separate repo:**

• Navigate to `Application path`
• Read the application's `## Arness` config, code patterns, and architecture
• Scan for the same dependency/entry point files
• If the path is unreachable, inform the user and ask them to describe the application stack manually

**Infra-only:**

• No application to analyze directly
• Ask the user to describe: language/framework, services (web, API, workers), databases, build commands, runtime requirements
• Proceed with user-provided context

---

Step 2: Check Existing Container Configurations

Scan for existing container files:

• `Dockerfile`, `Dockerfile.*`, `*.Dockerfile`
• `docker-compose.yml`, `docker-compose.yaml`, `compose.yml`, `compose.yaml`, `docker-compose.*.yml`
• `.dockerignore`

**If existing files found:** Present findings: "I found existing container configurations: [list files]."

Ask (using `AskUserQuestion`):

**"What would you like to do with existing container configurations?"**

Options: 1. **Replace** -- Generate new configurations (existing files will be overwritten after your approval) 2. **Augment** -- Keep existing files and add missing configurations 3. **Review only** -- Run a security audit on the existing files without generating new ones

**If the user chooses Review only:** Skip to Step 5 (security audit) with existing files.

**If no existing files found:** Continue to Step 3.

---

Step 3: Determine Container Strategy

Based on the application analysis from Step 1, determine what container files are needed.

**Single-service applications:**

• Generate: `Dockerfile`, `.dockerignore`
• Optionally generate `docker-compose.yml` if the app depends on external services (database, cache, queue)

**Multi-service applications:**

• Generate: one `Dockerfile` per service (or `Dockerfile.<service>`)
• Generate: `docker-compose.yml` with all services
• Generate: `.dockerignore`

Ask the user to confirm the container strategy:

"Based on your application, I plan to generate:

• [list of files to generate]
• Multi-stage builds for [production optimization / smaller images]
• [Development docker-compose with hot reload / Production-only compose]

Does this look right, or would you like to adjust?"

---

Step 4: Invoke Specialist Agent for Generation

Load the appropriate reference files based on the detected technology stack:

> Read the local override or plugin default for `dockerfile-patterns.md`.

If multi-service or compose is needed:

> Read the local override or plugin default for `compose-patterns.md`.

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 CON