agentleFS
Sign inStart free
vivek-viswanatvivek-viswanat/dev-arsenal/skills/docker-image-optimizer-devops/SKILL.md

Docker Image Optimizer Devops

Skill4 starsChanged 8 months agoMITView on GitHub

Audits and refactors Dockerfiles to reduce image size, improve security and speed up build times.

  • Deletes or force-pushes
  • Installs packages

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 5 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when:

    line 7
  2. Distinctive:

    Separate Build from Runtime: Use a heavy image (with compilers/SDKs) for building, but copy ONLY the final binary/artifacts into a minimal …

    line 15
  3. Very specific:

    Named Stages: Use FROM base AS builder for readability.

    line 16
  4. Very specific:

    Prefer Minimal: Default to alpine (≈5MB) or debian-slim (≈30MB) over ubuntu:latest (≈75MB).

    line 19
  5. Very specific:

    Order Matters: Place instructions that change least often (like RUN apt-get update) at the top.

    line 23
  6. Very specific:

    No-Install-Recommends: Always use --no-install-recommends with apt.

    line 28
  7. Distinctive:

    Cache Cleaning: Remove package manager caches in the *same* layer as the installation.

    line 29
  8. Very specific:

    Production Only: Ensure devDependencies or build-only headers never reach the final stage.

    line 30
  9. Very specific:

    Exclusion: Every Docker project MUST have a .dockerignore to prevent .git, node_modules, tests/, and local logs from leaking into the build …

    line 33
  10. Distinctive:

    When a user provides a Dockerfile, perform a Size Audit first.

    line 36
  11. Distinctive:

    If the image is single-stage, provide a Refactored Multi-Stage Version.

    line 37
  12. Very specific:

    Check for "Magic Versions" and suggest pinning specific tags (e.g., node:22.1.0-alpine instead of node:latest).

    line 38

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Context

Use this skill when:

  1. Creating a new Dockerfile
  2. A user complains about "slow builds" or "large images"
  3. Reviewing container security (reducing attack surface)

Optimization Pillars

1. Multi-Stage Strategy (The 2026 Standard)

  • Separate Build from Runtime: Use a heavy image (with compilers/SDKs) for building, but copy ONLY the final binary/artifacts into a minimal runtime image (Alpine or Scratch).
  • Named Stages: Use FROM base AS builder for readability.

2. Base Image Selection

  • Prefer Minimal: Default to alpine (≈5MB) or debian-slim (≈30MB) over ubuntu:latest (≈75MB).
  • Distroless: For production, suggest gcr.io/distroless to remove all shells and package managers.

3. Layer Management & Caching

  • Order Matters: Place instructions that change least often (like RUN apt-get update) at the top. Place source code COPY commands at the bottom.
  • Atomic RUNs: Combine related commands using && and \ to prevent intermediate layer bloat. Example: RUN apt-get update && apt-get install -y --no-install-recommends pkg && rm -rf /var/lib/apt/lists/*

4. Dependency Hygiene

  • No-Install-Recommends: Always use --no-install-recommends with apt.
  • Cache Cleaning: Remove package manager caches in the same layer as the installation.
  • Production Only: Ensure devDependencies or build-only headers never reach the final stage.

5. The .dockerignore File

  • Exclusion: Every Docker project MUST have a .dockerignore to prevent .git, node_modules, tests/, and local logs from leaking into the build context.

Instructions for the Agent

  • When a user provides a Dockerfile, perform a Size Audit first.
  • If the image is single-stage, provide a Refactored Multi-Stage Version.
  • Check for "Magic Versions" and suggest pinning specific tags (e.g., node:22.1.0-alpine instead of node:latest).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free