Dockerfile Multi-Stage Refactor

What this skill does

Rewrites a single-stage Dockerfile as a multi-stage build that separates compile-time and runtime dependencies, then proves the resulting image is at least 30% smaller. The skill produces both the new Dockerfile and a size-delta report.

Inputs

• dockerfile_path: path to the source Dockerfile.
• language_hint: one of node, python, go, rust, java. Drives stage selection.
• image_tag (optional): tag to use for the comparison build. Defaults to audit-temp.

Steps

1. Run docker build -t <image_tag>:before -f <dockerfile_path> . and record docker image inspect <image_tag>:before --format '{{.Size}}'.
2. Parse the Dockerfile with a line-by-line scan, classifying each instruction as build-only (apt-get install build-essential, npm ci, go build) vs. runtime (final CMD, runtime deps).
3. Choose stage bases by language: Node uses node:20 builder + gcr.io/distroless/nodejs20; Go uses golang:1.22 builder + gcr.io/distroless/static; Python uses python:3.12 builder + python:3.12-slim.
4. Emit a new Dockerfile with FROM <builder> AS build, copy source, run build, then FROM <runtime>, COPY --from=build only the produced artifact paths.
5. Preserve the original EXPOSE, ENV, USER, and CMD in the runtime stage.
6. Run docker build -t <image_tag>:after -f <new_dockerfile> . and record the new size.
7. Compute delta_pct = 100 * (before - after) / before.
8. If delta_pct < 30, identify the three largest layers in :after via docker history --no-trunc --format '{{.Size}}\t{{.CreatedBy}}' and propose a follow-up.
9. Write the new Dockerfile to Dockerfile.multistage and the report to docker-refactor-report.md.

Output

Two files: Dockerfile.multistage (the rewritten build) and docker-refactor-report.md (a table with before/after sizes, layer breakdown, and a verdict line). Exit code 0 if the 30% target is met, else 2.

Verification

Run docker run --rm <image_tag>:after <healthcheck-cmd> (defaults to the original CMD) and confirm exit code 0. Diff docker image inspect JSON between the two tags and verify both expose the same ports and run as the same user. If runtime behavior diverges, abort and restore Dockerfile.

Edge cases

• Dockerfile with FROM scratch: skip refactor, exit with note "already optimal".
• Build that needs runtime compilers (e.g., dynamic JIT extensions): keep them in the runtime stage and document the reason.
• Multi-arch builds (docker buildx): preserve --platform flags when invoking the comparison build.
• Source not present at cwd: fail fast — multi-stage refactor needs the build context to actually rebuild.