agentleFS
Sign inStart free
edjchapmanedjchapman/claude-code-config/skills/docker-patterns/SKILL.md

docker-patterns

Skill8 starsChanged 19 days agoMITView on GitHub

Container build, security, and caching conventions. Use when editing Dockerfiles, Compose files, build contexts, or .dockerignore.

  • Reads credentials

43 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use content-hash-cache-pattern, configure-ecc and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • royaluniondesign-sysSkill

    content-hash-cache-pattern

    Cache expensive file processing results using SHA-256 content hashes — path-independent, auto-invalidating, with service layer separation.

    Also in 14 projects that use this

  • royaluniondesign-sysSkill

    configure-ecc

    Interactive installer for Everything Claude Code — guides users through selecting and installing skills and rules to user-level or project-level directories, verifies paths, and optionally optimizes installed files.

    Also in 9 projects that use this

  • junimnjwSkill

    ralphinho-rfc-pipeline

    RFC-driven multi-agent DAG execution pattern with quality gates, merge queues, and work unit orchestration.

    Also in 9 projects that use this

  • Yog-SothoSkill

    pytorch-patterns

    PyTorch deep learning patterns and best practices for building robust, efficient, and reproducible training pipelines, model architectures, and data loading. Always activate when the user is writing PyTorch models or training scripts, reviewing deep learning code, debugging training loops or data pipelines, optimizing GPU memory or training speed, setting up reproducible experiments, implementing transfer learning or fine-tuning, or asks anything about nn.Module, DataLoader, autograd, AMP, or torch.compile.

    Also in 11 projects that use this

  • loulanyueSkill

    nuxt4-patterns

    Nuxt 4 app patterns for hydration safety, performance, route rules, lazy loading, and SSR-safe data fetching with useFetch and useAsyncData.

    Also in 7 projects that use this

  • junimnjwSkill

    carrier-relationship-management

    Codified expertise for managing carrier portfolios, negotiating freight rates, tracking carrier performance, allocating freight, and maintaining strategic carrier relationships. Informed by transportation managers with 15+ years experience. Includes scorecarding frameworks, RFP processes, market intelligence, and compliance vetting. Use when managing carriers, negotiating rates, evaluating carrier performance, or building freight strategies.

    Also in 7 projects that use this

  • +3 more from royaluniondesign-sys
  • +2 more from junimnjw

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 3 are distinctive, and 10 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use multi-stage builds to separate build dependencies from runtime

    line 10
  2. Very specific:

    Keep the final image as small as possible (use slim or alpine base images)

    line 13
  3. Very specific:

    Use .dockerignore to exclude unnecessary files from build context

    line 20
  4. Very specific:

    Always include: .git, node_modules, __pycache__, .env, *.log

    line 24
  5. Very specific:

    Never run as root -- use USER nonroot or create a dedicated user

    line 30
  6. Distinctive:

    Don't store secrets in images -- use environment variables or secrets managers

    line 31
  7. Very specific:

    Use COPY instead of ADD unless you need tar extraction

    line 34
  8. Very specific:

    Always define HEALTHCHECK in production Dockerfiles

    line 38
  9. Very specific:

    Use lightweight endpoints (/healthz) that check actual dependencies

    line 39
  10. Distinctive:

    Use named volumes for persistent data

    line 45
  11. Very specific:

    Use depends_on with health check conditions

    line 47
  12. Very specific:

    Use .env files for environment configuration

    line 48
  13. Very specific:

    Use profiles to group services by environment (dev, test, prod)

    line 50

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “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 Patterns

Multi-Stage Builds

  • Use multi-stage builds to separate build dependencies from runtime
  • Name stages for clarity: FROM node:20 AS builder
  • Copy only build artifacts into the final stage
  • Keep the final image as small as possible (use slim or alpine base images)

Layer Caching

  • Order instructions from least to most frequently changing
  • Copy dependency files (package.json, requirements.txt) before source code
  • Group related RUN commands with && to reduce layers
  • Use .dockerignore to exclude unnecessary files from build context

.dockerignore

  • Always include: .git, node_modules, __pycache__, .env, *.log
  • Mirror .gitignore patterns plus build artifacts
  • Exclude test files and documentation from production images

Security

  • Never run as root -- use USER nonroot or create a dedicated user
  • Don't store secrets in images -- use environment variables or secrets managers
  • Pin base image versions: python:3.12-slim not python:latest
  • Scan images for vulnerabilities with docker scout or trivy
  • Use COPY instead of ADD unless you need tar extraction

Health Checks

  • Always define HEALTHCHECK in production Dockerfiles
  • Use lightweight endpoints (/healthz) that check actual dependencies
  • Set appropriate intervals, timeouts, and retries
  • Health checks should complete quickly (< 5s)

Compose Best Practices

  • Use named volumes for persistent data
  • Define explicit networks for service isolation
  • Use depends_on with health check conditions
  • Use .env files for environment configuration
  • Define resource limits (mem_limit, cpus) for production
  • Use profiles to group services by environment (dev, test, prod)

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.

Reviews can't be read right now.

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.

Check your setup, free