docker-image-management
Skill4 starsChanged 11 days agoMITView on GitHub
Guide for creating, building, and managing Docker images and containers. Use this skill when working with Dockerfiles, containerization, image building, registry operations, container runtime, storage mounts, image security, Docker Compose, or any Docker-related task including optimization, debugging, and best practices.
- Reads credentials
- Installs packages
In this repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- skills/client-config-opencode/references/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- repository-reviewSkill
- weekly-skill-refreshSkill
- skill-maintenanceSkill
- about-me-skill-creatorSkill
- agent-creator-claudecodeSkill
- agent-creator-codexSkill
- agent-creator-copilotSkill
- agent-creator-opencodeSkill
- client-config-claudecodeSkill
- client-config-codexSkill
- client-config-copilotcliSkill
- client-config-opencodeSkill
- copilot-instruction-creatorSkill
- copilot-workerSkill
- git-commit-messagesSkill
- google-style-docsSkill
- handoffSkill
- markdownlint-validatorSkill
- mkdocs-site-managementSkill
- skill-routerSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Always load the relevant reference file before giving guidance on that topic.
- Very specific: line 25
Run as a non-root USER — always.
- Very specific: line 26
Never embed secrets in image layers.
- Very specific: line 27
Use official or verified publisher base images.
- Distinctive: line 33
Use multi-stage builds to keep production images free of build tools.
- Very specific: line 43
Use docker buildx build for advanced features (multi-platform, custom builders).
- Distinctive: line 48
Before writing a Dockerfile, identify:
- Very specific: line 56
Read references/build.md for Dockerfile instruction guidance and patterns.
- Very specific: line 84
Read references/run.md for full runtime options.
- Very specific: line 91
Read references/registry.md for authentication, tagging strategy, and vulnerability scanning.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Docker Image Management Skill
This skill covers the full lifecycle of Docker container images: authoring Dockerfiles, building with BuildKit, running containers, managing storage, pushing to registries, and scanning for vulnerabilities.
Quick Decision Guide
| Task | Load |
| Writing or optimizing a Dockerfile, multi-stage builds, build cache, build secrets | references/build.md |
| Running containers, networking, mounts, resource limits, capabilities | references/run.md |
| Tagging, pushing/pulling, Docker Hub auth, image scanning (Scout) | references/registry.md |
| Multi-container apps | references/docker-compose-examples.yml |
| Dockerfile templates for Node, Python, Go, Java, etc. | references/dockerfile-templates.md |
Always load the relevant reference file before giving guidance on that topic.
Core Principles
Security first
- Run as a non-root
USER— always. Docker Scout flags containers running as root. - Never embed secrets in image layers. Use build-time
--secretmounts or runtime env vars. - Use official or verified publisher base images. Pin to a specific tag (e.g.
node:22-alpine) or digest for reproducibility.
Layer efficiency
- Order
COPY/RUNinstructions from least-to-most frequently changed to maximize cache reuse. - Install dependencies before copying app code.
- Combine
apt-get update && apt-get installin a singleRUN; clean up in the same layer. - Use multi-stage builds to keep production images free of build tools.
BuildKit is the default
BuildKit is enabled by default in Docker Engine 23.0+ and Docker Desktop. It provides:
- Parallel stage execution
- Efficient layer caching
- Secret mounts (
--secret) - SSH forwarding (
--ssh) - Inline cache export
Use docker buildx build for advanced features (multi-platform, custom builders). docker build wraps Buildx.
Standard Workflow
1. Analyze requirements
Before writing a Dockerfile, identify:
- Runtime vs. build-only dependencies
- Exposed ports
- Required env vars and config
- Persistent data (volumes)
- Security context (user, capabilities)
2. Write the Dockerfile
Read references/build.md for Dockerfile instruction guidance and patterns.
Copy a starter from references/dockerfile-templates.md and customize.
3. Create .dockerignore
Exclude node_modules/, .git/, .env, *.log, build output dirs, and test files.
See references/dockerignore-template for language-specific patterns.
4. Build the image
# Standard build
docker build -t myapp:1.0 .
# Build + push in one step
docker build --push -t registry.example.com/myapp:1.0 .
# Pull fresh base, bypass cache
docker build --pull --no-cache -t myapp:1.0 .
# Pass a build secret (never use --build-arg for secrets)
docker build --secret id=mysecret,src=.env -t myapp:1.0 .5. Run and test
docker run --rm -p 3000:3000 myapp:1.0
docker logs <container>
docker exec -it <container> shRead references/run.md for full runtime options.
6. Tag and push
docker tag myapp:1.0 myorg/myapp:1.0
docker push myorg/myapp:1.0Read references/registry.md for authentication, tagging strategy, and vulnerability scanning.
Debugging Checklist
| Symptom | Action |
| Container exits immediately | docker logs <container> |
| Port not reachable | Check -p HOST:CONTAINER, verify EXPOSE |
| File not found in container | Check .dockerignore, verify COPY paths |
| Permission denied | Check USER and file ownership |
| Large image size | Use multi-stage build, alpine base, .dockerignore |
| Build cache not working | Verify COPY order; check if files changed |
| Secret exposed in layer | Use --secret mount, not --build-arg |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

