mcpField
D
docker

docker

github.com/ulpi-ioCloud & DevOps5122 installsUpdated 9w ago
Repository

About docker

A Docker skill that routes container-related work through a focused set of project references. It guides developers through secure, reproducible builds and asks them to verify the resulting image and runtime health.

Key features

  1. 01Task-based reference selection
  2. 02Multi-stage build guidance
  3. 03Image and container security rules
  4. 04Build and runtime verification checklist

Use cases

  1. 01Writing or editing a Dockerfile
  2. 02Configuring Compose services
  3. 03Investigating build or container issues

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/ulpi-io/skills --skill docker

After installing, type/dockerin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
build-context.md
buildkit.md
ci-cd.md
compose.md
debugging.md
dockerfile.md
health-checks.md
image-optimization.md
language-patterns.md
multi-stage.md
networking.md
registry.md
security.md
stack.md
volumes.md

Details

From the project README
This skill is a routing shell over the Docker reference set.

Non-negotiable rules:

  1. Read references/stack.md first to determine the project's base images, registry, and build conventions.
  2. Then load only the references needed for the actual task.
  3. Multi-stage builds by default — separate dependency install, build, and production stages.
  4. Non-root user in production — never run containers as root. Add a user and USER directive.
  5. No secrets in images — no ARG/ENV for passwords, no COPY .env, no secrets in build layers.
  6. Pin base image versions — node:22-slim, not node:latest. Use digest pinning for critical images.
  7. .dockerignore is mandatory — exclude node_modules, .git, .env, dist, test artifacts.
  8. Frozen lockfiles in builds — --frozen-lockfile / --ci for reproducible installs.

docker

Inputs

  • $request: The Docker task — Dockerfile, Compose, registry, optimization, or debugging target

Goal

Route Docker work through proven container patterns so images are small, secure, reproducible, and follow the project's infrastructure conventions.

Step 0: Read the stack contract

Always start with:

  • references/stack.md

That establishes: base images, registry, build tool (Docker/BuildKit/Podman), CI integration, and locked conventions.

Success criteria: The project's container infrastructure choices are explicit before writing any Dockerfile or Compose config.

Step 1: Load only the relevant references

Use the routing table to pick reference files. Do not bulk-load the full reference tree.

TaskRead
Base images, registry, build conventions, CIreferences/stack.md
Writing or editing a Dockerfilereferences/dockerfile.md
Multi-stage builds, layer optimization, cachingreferences/multi-stage.md
docker-compose services, networking, volumesreferences/compose.md
.dockerignore, build context optimizationreferences/build-context.md
Health checks, readiness, startup probesreferences/health-checks.md
Security: non-root, read-only FS, capabilities, scanningreferences/security.md
Image size optimization, distroless, slim, alpinereferences/image-optimization.md
Registry: push, pull, tagging, ECR/GCR/GHCR/DockerHubreferences/registry.md
BuildKit features, cache mounts, secret mountsreferences/buildkit.md
CI/CD: GitHub Actions, GitLab CI, build+push pipelinesreferences/ci-cd.md
Debugging: logs, exec, inspect, networking issuesreferences/debugging.md
Language-specific: Node.js, Python, Go, Rust, Javareferences/language-patterns.md
Volumes, bind mounts, tmpfs, named volumesreferences/volumes.md
Networking: bridge, host, overlay, DNS, port mappingreferences/networking.md

Multiple tasks? Read multiple files. The references are self-contained.

Success criteria: Only the task-relevant Docker conventions are in play.

Step 2: Implement with the core Docker guardrails

Keep these rules active:

  • multi-stage builds: deps → build → production
  • .dockerignore excludes everything unnecessary from build context
  • pin base image tags — never :latest in production
  • non-root USER in the final stage
  • COPY only what's needed in each stage — not the entire repo
  • health checks on every long-running service
  • no secrets in ARG, ENV, or COPY — use BuildKit --mount=type=secret
  • combine RUN commands to minimize layers — but keep readability
  • order layers from least to most frequently changing (deps before code)

Success criteria: The container is small, secure, reproducible, and follows the project's conventions.

Step 3: Verify the build

Use the narrowest relevant verification:

  • docker build succeeds
  • image size is reasonable for the language/framework
  • container starts and health check passes
  • .dockerignore excludes the right files (docker build --dry-run or check context size)
  • no secrets visible in docker history or docker inspect

Success criteria: The image builds, runs, and passes basic health validation.

Guardrails

  • Do not inline the whole Docker handbook in SKILL.md.
  • Do not skip references/stack.md.
  • Do not use latest tags for base images in production Dockerfiles.
  • Do not COPY . . without a proper .dockerignore.
  • Do not run containers as root.
  • Do not put secrets in build args or env vars baked into images.
  • Do not add disable-model-invocation; this is a normal domain skill.

When To Load References

  • references/stack.md Always.

  • then only the task-relevant files under references/

Output Contract

Report:

  1. which Docker references were loaded
  2. the build pattern chosen (multi-stage, single, etc.)
  3. the change made
  4. the verification run (build success, image size, health check)

Comments

Markdown supported