docker

Q: How do I install docker?

Run npx skills add https://github.com/ulpi-io/skills --skill docker in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/docker/ (personal) or .claude/skills/docker/ (project).

by ulpi-ioDevOps & Cloud

Write and change container infrastructure the way THIS project already builds and ships it, not by generic defaults — a Docker reference carrying the real conventions for Dockerfiles, multi-stage builds, Compose services, networking, volumes, health checks, registries, BuildKit, security hardening, CI/CD integration, and debugging. Holds the invariants that keep images small and safe: multi-stage builds, non-root runtime, pinned base images, no baked secrets, a mandatory .dockerignore, and frozen lockfiles — so an image lands small, secure, reproducible, and review-ready instead of merely building. Use when a task touches container configuration, images, or deployment infrastructure.

Installs: 121
Last 24h: —
Trending rank: —
Security: Not audited

Install

Works with every agent the skills CLI supports.

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

01
Install
Run the command in your project. The CLI asks which agents to install for.
02
Describe the task
Ask your agent for something this skill covers. It loads docker automatically when relevant.
03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

<EXTREMELY-IMPORTANT> This skill is a routing shell over the Docker reference set.

Non-negotiable rules:

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

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.

Task	Read
Base images, registry, build conventions, CI	`references/stack.md`
Writing or editing a Dockerfile	`references/dockerfile.md`
Multi-stage builds, layer optimization, caching	`references/multi-stage.md`
docker-compose services, networking, volumes	`references/compose.md`
.dockerignore, build context optimization	`references/build-context.md`
Health checks, readiness, startup probes	`references/health-checks.md`
Security: non-root, read-only FS, capabilities, scanning	`references/security.md`
Image size optimization, distroless, slim, alpine	`references/image-optimization.md`
Registry: push, pull, tagging, ECR/GCR/GHCR/DockerHub	`references/registry.md`
BuildKit features, cache mounts, secret mounts	`references/buildkit.md`
CI/CD: GitHub Actions, GitLab CI, build+push pipelines	`references/ci-cd.md`
Debugging: logs, exec, inspect, networking issues	`references/debugging.md`
Language-specific: Node.js, Python, Go, Rust, Java	`references/language-patterns.md`
Volumes, bind mounts, tmpfs, named volumes	`references/volumes.md`
Networking: bridge, host, overlay, DNS, port mapping	`references/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:

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

FAQ

What does the docker skill do?

How do I install docker?

Run npx skills add https://github.com/ulpi-io/skills --skill docker in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/docker/ (personal) or .claude/skills/docker/ (project).

Which AI agents can use docker?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is docker safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains docker?

It is published by ulpi-io in ulpi-io/skills. It has 121 recorded installs.

More from ulpi-io/skills

View all →

frontend-design-ui-ux

ulpi-io/skills

Produce a distinctive, LOCKED design language plus an implementation-ready UX/UI spec, written to .ulpi/design/: a per-brief visual identity (palette, type, signature), the design system to build on, user flows and states, component briefs, and accessibility constraints. Commits to a bold aesthetic direction, bans AI-slop by name, and locks the identity so every screen and future session stays consistent. Can visit inspiration links with the browse skill to extract real design DNA. Ends with a build handoff that a delegated engineering agent implements — a DESIGN-SPEC skill that produces the spec, never production UI code. Use for new features, redesigns, or design-system work where the build should follow a locked spec.

Frontend & Design2.4K installs