← ClaudeAtlas

dockerfile-lintlisted

Lint a Dockerfile for safety, size, and correctness using hadolint plus project rules (non-root FINAL stage, multi-stage, pinned base, healthcheck, BuildKit secret handling). Run before merging any Dockerfile change and after a base-image bump. Covers the Dockerfile only — `release-security` scans the built image for CVEs, SBOM, and signatures.
adnanmokhtar/refract · ★ 1 · Code & Development · score 77
Install: claude install-skill adnanmokhtar/refract
# dockerfile-lint Catch unsafe + bloated Dockerfiles before they hit a registry. ## Premise Find real issues, cite the Dockerfile line and the rule that fires. Hadolint findings are reported with their rule code (DL3008, DL3007, etc.). Project-rule failures (HEALTHCHECK missing, final-stage USER root, no `.dockerignore`) cite the actual line absent or the value detected. Image size, layer count, and "secret in history" come from `docker inspect` / `docker history` output captured during a real build — not from reading the source alone. **Every check below reads the FINAL stage.** A multi-stage Dockerfile has one stage that ships and N that do not, and almost every false pass in this skill's history came from a check that answered about the builder. `USER node` in the build stage does not make the runtime non-root. ## Halt conditions - Refuse to report "no HEALTHCHECK" without grepping the file. - Refuse to flag "secret in image" without showing the `docker history` line that contains it. - Halt if `docker build` failed — fix the build first, then lint. - Don't dismiss a hadolint warning without naming why it's acceptable. - `:latest` tag = block. Untagged `FROM` = block (it resolves to `:latest`). Final-stage `USER root` (or no `USER` at all in the final stage) = block. Secrets baked in = critical (rotate the leaked credential). ## When to use - Before merging a new Dockerfile or any change to one. - After a base-image bump to confirm the pin is still tight. - After a