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.
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:
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
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)
1---2name: docker3description: 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.4---5
6<EXTREMELY-IMPORTANT>
7This skill is a routing shell over the Docker reference set.
8
9Non-negotiable rules:
101. Read `references/stack.md` first to determine the project's base images, registry, and build conventions.
112. Then load only the references needed for the actual task.
123. **Multi-stage builds by default** — separate dependency install, build, and production stages.
134. **Non-root user in production** — never run containers as root. Add a user and `USER` directive.
145. **No secrets in images** — no `ARG`/`ENV` for passwords, no `COPY .env`, no secrets in build layers.
156. **Pin base image versions** — `node:22-slim`, not `node:latest`. Use digest pinning for critical images.
167. **`.dockerignore` is mandatory** — exclude `node_modules`, `.git`, `.env`, `dist`, test artifacts.
178. **Frozen lockfiles in builds** — `--frozen-lockfile` / `--ci` for reproducible installs.
18</EXTREMELY-IMPORTANT>
19
20# docker
21
22## Inputs
23
24- `$request`: The Docker task — Dockerfile, Compose, registry, optimization, or debugging target
25
26## Goal
27
28Route Docker work through proven container patterns so images are small, secure, reproducible, and follow the project's infrastructure conventions.
29
30## Step 0: Read the stack contract
31
32Always start with:
33
34- `references/stack.md`
35
36That establishes: base images, registry, build tool (Docker/BuildKit/Podman), CI integration, and locked conventions.
37
38**Success criteria**: The project's container infrastructure choices are explicit before writing any Dockerfile or Compose config.
39
40## Step 1: Load only the relevant references
41
42Use the routing table to pick reference files. Do not bulk-load the full reference tree.
43
44| Task | Read |
45|------|------|
46| Base images, registry, build conventions, CI | `references/stack.md` |
47| Writing or editing a Dockerfile | `references/dockerfile.md` |
48| Multi-stage builds, layer optimization, caching | `references/multi-stage.md` |
49| docker-compose services, networking, volumes | `references/compose.md` |
50| .dockerignore, build context optimization | `references/build-context.md` |
51| Health checks, readiness, startup probes | `references/health-checks.md` |
52| Security: non-root, read-only FS, capabilities, scanning | `references/security.md` |
53| Image size optimization, distroless, slim, alpine | `references/image-optimization.md` |
54| Registry: push, pull, tagging, ECR/GCR/GHCR/DockerHub | `references/registry.md` |
55| BuildKit features, cache mounts, secret mounts | `references/buildkit.md` |
56| CI/CD: GitHub Actions, GitLab CI, build+push pipelines | `references/ci-cd.md` |
57| Debugging: logs, exec, inspect, networking issues | `references/debugging.md` |
58| Language-specific: Node.js, Python, Go, Rust, Java | `references/language-patterns.md` |
59| Volumes, bind mounts, tmpfs, named volumes | `references/volumes.md` |
60| Networking: bridge, host, overlay, DNS, port mapping | `references/networking.md` |
61
62Multiple tasks? Read multiple files. The references are self-contained.
63
64**Success criteria**: Only the task-relevant Docker conventions are in play.
65
66## Step 2: Implement with the core Docker guardrails
67
68Keep these rules active:
69
70- multi-stage builds: deps → build → production
71- `.dockerignore` excludes everything unnecessary from build context
72- pin base image tags — never `:latest` in production
73- non-root `USER` in the final stage
74- `COPY` only what's needed in each stage — not the entire repo
75- health checks on every long-running service
76- no secrets in `ARG`, `ENV`, or `COPY` — use BuildKit `--mount=type=secret`
77- combine `RUN` commands to minimize layers — but keep readability
78- order layers from least to most frequently changing (deps before code)
79
80**Success criteria**: The container is small, secure, reproducible, and follows the project's conventions.
81
82## Step 3: Verify the build
83
84Use the narrowest relevant verification:
85
86- `docker build` succeeds
87- image size is reasonable for the language/framework
88- container starts and health check passes
89- `.dockerignore` excludes the right files (`docker build --dry-run` or check context size)
90- no secrets visible in `docker history` or `docker inspect`
91
92**Success criteria**: The image builds, runs, and passes basic health validation.
93
94## Guardrails
95
96- Do not inline the whole Docker handbook in `SKILL.md`.
97- Do not skip `references/stack.md`.
98- Do not use `latest` tags for base images in production Dockerfiles.
99- Do not `COPY . .` without a proper `.dockerignore`.
100- Do not run containers as root.
101- Do not put secrets in build args or env vars baked into images.
102- Do not add `disable-model-invocation`; this is a normal domain skill.
103
104## When To Load References
105
106- `references/stack.md`
107 Always.
108
109- then only the task-relevant files under `references/`
110
111## Output Contract
112
113Report:
114
1151. which Docker references were loaded
1162. the build pattern chosen (multi-stage, single, etc.)
1173. the change made
1184. the verification run (build success, image size, health check)