Claude Prompt to Optimize Docker Image Layers

What this prompt does

This prompt has the AI analyze and optimize your Dockerfile for [language]/[framework] to shrink image size and improve build cache efficiency. You provide the [current_size] and [build_time], and it reorders layers around your [change_frequency], separates dependency installation from source copying for [package_manager], strips unnecessary files, compares [current_base] against alpine/distroless/scratch, applies build-arg and cache-mount tricks for [cacheable_operations], advises on squashing, and produces a before/after comparison aiming under [target_size].

The structure works because cache efficiency depends almost entirely on ordering: instructions that change rarely must come before instructions that change often. By telling the model what [change_frequency] looks like — source code changing constantly while dependencies change weekly — it can place the dependency layer above the source copy so most builds reuse the cache. Comparing base images explicitly forces the size-versus-compatibility trade-off into the open instead of defaulting to a bloated base. Anchoring the request to your real [current_size] and [build_time] also gives the model a concrete starting point, so its before/after numbers are grounded rather than hypothetical.

When to use it

• Your builds have gotten slow and you suspect poor layer ordering is wrecking the cache.
• An image has ballooned in size and you want a layer-by-layer breakdown of where the weight is.
• You want to evaluate moving from a full base image to alpine, distroless, or scratch.
• You need the optimal COPY strategy to separate [package_manager] dependencies from application source.
• You are paying for slow CI and want cache-friendly ordering plus cache mounts for [cacheable_operations].
• You have a concrete [target_size] to hit and want a measurable before/after.

Example output

Expect a rewritten Dockerfile with reordered instructions, a separated dependency layer, a multi-stage build that drops dev dependencies and build tools from the final image, and a base-image recommendation with size and security trade-offs spelled out. Alongside it you get a before/after table showing layer-by-layer size reduction and an estimate of how close the result lands to [target_size].

Pro tips

• Describe [change_frequency] accurately; the entire layer-ordering strategy hinges on which instructions change often versus rarely.
• Separate the dependency install from the source COPY for [package_manager] so editing a source file does not invalidate the dependency cache.
• Treat the base-image choice as case-by-case: distroless and scratch shrink size and attack surface but remove the shell and tools you may need for debugging.
• Use --mount=type=cache for [cacheable_operations] like package installs so you stop re-downloading the same artifacts every build.
• Be skeptical of squashing; combining RUN steps cleans up intermediate files but can hurt cache reuse, so squash only where the layers truly belong together.
• Verify the real [current_size] and [build_time] before and after so the before/after comparison reflects your environment, not an assumption.
• Drop dev dependencies, tests, and docs from the final stage of your [framework] build; they are common stowaways that inflate the image without ever running in production.