agentsclimarketplace

Docker

Skill sordi-ai/skill-everything/skills/docker

Git-versioned agent memory: agents that never make the same mistake twice. Anthropic-Skill folder standard, multi-runtime (Claude Code, Cursor, Gemini CLI, OpenCode).

Install
npx -y skills add sordi-ai/skill-everything --skill docker

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 17 stars17 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

Apply when writing or reviewing Dockerfiles, docker compose files, or container build pipelines. Covers layer caching, multi-stage builds, security hardening, and compose conventions.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.4 KB, as published. Nobody here has run it

Sub-Skill: Docker / Container Conventions

Purpose: Prevent common container mistakes — busted layer caches, bloated images, insecure defaults, and compose misconfigurations — before they reach CI or production.


Rules

Layer Ordering & Cache

  1. Dependency layer first. Always install dependencies in a separate layer before copying application source, so a source change does not invalidate the package cache. Reference: ERR-2026-020
  2. Copy only what's needed early. Before copying the full source tree, copy only the dependency manifest files (e.g., requirements.txt, package.json, pyproject.toml) so the install layer is cached independently.
  3. Minimise layer count. Prefer chaining related RUN commands with && and \ continuations rather than issuing one RUN per command; each RUN creates a new layer.
  4. Order by change frequency. Always place instructions that change rarely (OS packages, global tools) before instructions that change often (app source, config files).

Multi-Stage Builds

  1. Use multi-stage for compiled artefacts. Always use a builder stage to compile or bundle, then copy only the final artefact into a minimal runtime stage; never ship build toolchains in the production image.
  2. Name every stage. Use AS <name> on every FROM line so later stages and docker build --target calls are readable and stable.
  3. Pin the runtime base image. Always pin base images to a specific digest or immutable tag (e.g., python:3.12.3-slim) in the runtime stage; never use latest in production Dockerfiles.

Security

  1. Run as non-root. Always create a dedicated non-root user and switch to it with USER before the final CMD/ENTRYPOINT; never run application processes as root inside a container.
  2. Never embed secrets in image layers. Never pass secrets via ARG or ENV in a Dockerfile; use Docker BuildKit --secret mounts or runtime environment injection instead.
  3. Scan images before push. Before pushing any image to a registry, run an image vulnerability scanner (e.g., trivy image, docker scout) and fail the pipeline on critical CVEs.
  4. Prefix docker run -v from Git Bash with MSYS_NO_PATHCONV=1. Always prefix docker run -v calls issued from Git Bash or MSYS on Windows with MSYS_NO_PATHCONV=1 to prevent path mangling. Reference: ERR-2026-013

.dockerignore & Context

  1. Maintain a .dockerignore. Always keep a .dockerignore at the repo root that excludes .git, test fixtures, local env files, and build artefacts; a large build context slows every build and may leak secrets.

Health Checks & Signal Handling

  1. Declare a HEALTHCHECK. Always add a HEALTHCHECK instruction so orchestrators (Compose, Kubernetes) can detect unhealthy containers without external probes.
  2. Use exec-form ENTRYPOINT. Always write ENTRYPOINT in exec form (["executable", "arg"]) rather than shell form so the process receives OS signals directly and docker stop terminates it cleanly.

Compose Conventions

  1. Set resource limits in compose. Always declare deploy.resources.limits (CPU and memory) for every service in docker-compose.yml to prevent a runaway container from starving the host.
  2. Use compose profiles for optional services. Prefer assigning optional services (e.g., observability stacks, seed jobs) to named profiles so docker compose up starts only the core services by default.
  3. Isolate networks per stack. Avoid using the default bridge network across unrelated stacks; define explicit named networks and attach only the services that need to communicate.

See also

  • skills/code-quality/SKILL.md — general layering and change-frequency ordering principles
  • skills/review-deployment/SKILL.md — deployment checklist that includes image scanning and migration ordering

Notes

  • ERR-2026-020 is the canonical reference for layer-cache busting caused by copying source before installing dependencies.
  • ERR-2026-013 covers MSYS path mangling on Windows when using docker run -v.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.