dockerfile-linter
Skill48 starsChanged 17 days agoMITView on GitHub
Checks a Dockerfile for common problems such as unpinned base images, running as root, ADD instead of COPY, secrets in ENV or ARG and apt-get without cleanup. Use when the user asks to review, harden or slim down a Dockerfile.
- Installs packages
In this repository15 other files it gives its agents.
- api-endpoint-testerSkill
- changelog-generatorSkill
- commit-message-writerSkill
- csv-profilerSkill
- env-file-auditorSkill
- json-diffSkill
- log-analyzerSkill
- meeting-notes-to-actionsSkill
- pr-description-writerSkill
- python-code-smellsSkill
- readme-doctorSkill
- secure-code-reviewSkill
- skill-authorSkill
- sql-query-reviewerSkill
- todo-extractorSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Before a pull request that adds or changes a Dockerfile.
- Distinctive: line 19
When hardening a container that runs in production.
≈ “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.
Files
Dockerfile linter
A small rule set that catches the problems seen most often in real Dockerfiles, with line numbers.
When to use
- The user asks for a review of a Dockerfile, or says an image is too big or insecure.
- Before a pull request that adds or changes a Dockerfile.
- When hardening a container that runs in production.
How to run
python scripts/lint_dockerfile.py DockerfileRules
| Rule | Meaning |
DF001 | base image uses latest or has no tag, so builds are not reproducible |
DF002 | no USER instruction, the container runs as root |
DF003 | ADD used where COPY is enough (ADD is only needed for archives and URLs) |
DF004 | apt-get install without --no-install-recommends |
DF005 | apt-get update without removing /var/lib/apt/lists in the same layer |
DF006 | a secret-looking name (password, token, secret, api key) is set with ENV or ARG |
DF007 | sudo is used inside the image |
DF008 | no HEALTHCHECK (informational) |
Output
JSON with instructions (count) and findings, a list of {"line", "rule", "severity", "message"}.
Severity is warning or info. The exit code is 1 when there is at least one warning.
After running
Fix DF006 first, a secret baked into an image layer is exposed to anyone who can pull the image. Then DF002
and DF001. Suggest multi-stage builds when the image installs compilers.
Errors
A missing file exits with code 2.
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
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.