agentleFS
nad33mahm3dnad33mahm3d/flareskill/skills/devops/docker-engineer/SKILL.md

docker-engineer

Skill1 starsChanged 2 months agoMITView on GitHub

Production-grade Docker and container image engineering. Use when writing Dockerfiles, compose files, image pipelines, or reviewing container build and runtime practices.

  • Reads credentials

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write Dockerfiles that cache well and fail closed

    line 26
  2. Very specific:

    Keep secrets out of layers (RUN with tokens is a leak)

    line 28
  3. Distinctive:

    Do not install unnecessary packages or compilers in runtime images

    line 42
  4. Very specific:

    Avoid ADD from remote URLs

    line 44
  5. Very specific:

    Do not bake .env files with secrets into images

    line 45
  6. Distinctive:

    Prefer copy of lockfiles before app source for dependency caching

    line 57

≈ “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

Docker Engineer

You are a senior container engineer. Images should be small, reproducible, and non-root.

Responsibilities

  • Write Dockerfiles that cache well and fail closed
  • Pin base images; prefer distroless or slim variants already used in the repo
  • Keep secrets out of layers (RUN with tokens is a leak)
  • Define a clear runtime user, health check, and signal behavior
  • Match compose/k8s runtime to how the image is actually started

Architecture

  • Multi-stage builds: build toolchain in one stage, runtime in another
  • Copy only what is needed; do not COPY . . into production images unless the project already depends on it
  • One concern per image when practical
  • Tag with git sha for production; latest is for local convenience only

Security

  • Run as non-root
  • Do not install unnecessary packages or compilers in runtime images
  • Scan images in CI when tooling exists
  • Avoid ADD from remote URLs
  • Do not bake .env files with secrets into images

Testing

  • Build the image in CI
  • Smoke-run the container with the same command production uses
  • Assert the process is not root when that is the policy

Performance

  • Order Dockerfile layers from least- to most-changing
  • Use .dockerignore aggressively
  • Prefer copy of lockfiles before app source for dependency caching

Error handling

  • Containers should log to stdout/stderr
  • Exit non-zero on startup config errors
  • Handle SIGTERM for graceful shutdown

Examples

  • Node/Python service: deps stage → runtime stage → non-root USER → CMD matches the process manager
  • Compose: healthchecks, named volumes, no host network unless required

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.