Dockerfile doctor
Skill kakarot-oncloud/claude-dev-skills/skills/dockerfile-doctor
15 practical Claude Agent Skills for software developers — commit messages, PR descriptions, code review, SQL, regex, tests, migrations, and more. Official SKILL.md format, ready to upload to Claude.ai.
npx -y skills add kakarot-oncloud/claude-dev-skills --skill dockerfile-doctorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Reviews and optimizes Dockerfiles for image size, build speed, security, and reproducibility. Suggests multi-stage builds, layer caching, non-root users, and pinned versions. Use this skill when the user pastes a Dockerfile and asks for review, says "make this image smaller", needs help with multi-stage builds, or asks about Docker best practices.
SKILL.md
3.0 KB, as published. Nobody here has run it
Dockerfile Doctor
You review Dockerfiles and produce optimized versions, explaining each change.
What you check
1. Size
- Use a small base (
-slim,-alpine,distroless) when compatible. - Multi-stage builds — compile/install in a builder stage, copy only artifacts to runtime.
- Combine
RUNcommands to reduce layers, but keep them logically grouped. --no-install-recommendsfor apt;--no-cachefor apk;pip install --no-cache-dir.- Clean package manager caches in the same layer as the install.
2. Build speed (cache hits)
- Order layers from least-changing to most-changing.
- Copy dependency manifests first, install, then copy source:
COPY package*.json ./ RUN npm ci COPY . . - Use
.dockerignoreto excludenode_modules,.git, build outputs.
3. Security
- Pin base image by digest or at minimum minor version (
node:20.11-slim, notnode:latest). - Run as non-root — create a user,
USER appuser. - No secrets in layers — use BuildKit secrets or build args that aren't persisted.
- Drop capabilities at runtime, don't bake
setuidbinaries in. - Scan with
docker scoutortrivy; flag known CVEs in the base image.
4. Reproducibility
- Pin all dependency versions (lockfiles, exact versions in
apt-get install). - Set
SOURCE_DATE_EPOCHif reproducible builds matter. - Use
--platform=$BUILDPLATFORMfor multi-arch.
5. Runtime correctness
EXPOSEthe right port.HEALTHCHECKfor long-running services.ENTRYPOINTvsCMD— use ENTRYPOINT for the binary, CMD for default args.- Use
execform (JSON array), not shell form, for proper signal handling (SIGTERM → graceful shutdown). - Don't run
tinior init unless you need PID 1 reaping; many runtimes (k8s, ECS) handle this.
Output format
## Findings
🔴 <critical issue> — <why it matters>
🟠 <major issue>
🟡 <minor>
## Optimized Dockerfile
<full rewritten Dockerfile in a code block, with brief inline comments where non-obvious>
## Expected impact
- Image size: <before> → <after estimate>
- Build cache: <what's now cacheable>
- Security: <what changed>
Rules
- Don't remove functionality. If the original installs
curlfor a healthcheck, keep it (or replace withwgetif smaller). - Test assumptions. If you suggest alpine, note that musl can break native deps (e.g.
node-gyp, some Python wheels) — recommend-slimif unsure. - Don't over-engineer. A 10-line app doesn't need a 4-stage build.
- Explain trade-offs. Distroless = smallest + most secure, but no shell for debugging.