docker-development
Skill0 starsChanged 7 months agoMITView on GitHub
Docker and container development agent skill and plugin for Dockerfile optimization, docker-compose orchestration, multi-stage builds, and container security hardening. Use when: user wants to optimize a Dockerfile, create or improve docker-compose configurations, implement multi-stage builds, audit container security, reduce image size, or follow container best practices. Covers build performance, layer caching, secret management, and production-ready container patterns.
- Reads credentials
- Deletes or force-pushes
- Installs packages
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Not a Docker tutorial — a set of concrete decisions about how to build containers that don't waste time, space, or attack surface.
- Distinctive: line 45
If the user has a Dockerfile or wants to containerize something → this skill applies.
- Distinctive: line 57
Check for common anti-patterns
- Distinctive: line 90
Add inline comments explaining each decision
- Distinctive: line 139
Add dev/prod profile annotations
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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 Development
Smaller images. Faster builds. Secure containers. No guesswork.
Opinionated Docker workflow that turns bloated Dockerfiles into production-grade containers. Covers optimization, multi-stage builds, compose orchestration, and security hardening.
Not a Docker tutorial — a set of concrete decisions about how to build containers that don't waste time, space, or attack surface.
Slash Commands
| Command | What it does |
/docker:optimize | Analyze and optimize a Dockerfile for size, speed, and layer caching |
/docker:compose | Generate or improve docker-compose.yml with best practices |
/docker:security | Audit a Dockerfile or running container for security issues |
When This Skill Activates
Recognize these patterns from the user:
- "Optimize this Dockerfile"
- "My Docker build is slow"
- "Create a docker-compose for this project"
- "Is this Dockerfile secure?"
- "Reduce my Docker image size"
- "Set up multi-stage builds"
- "Docker best practices for [language/framework]"
- Any request involving: Dockerfile, docker-compose, container, image size, build cache, Docker security
If the user has a Dockerfile or wants to containerize something → this skill applies.
Workflow
/docker:optimize — Dockerfile Optimization
- Analyze current state
- Read the Dockerfile
- Identify base image and its size
- Count layers (each RUN/COPY/ADD = 1 layer)
- Check for common anti-patterns
Apply optimization checklist
BASE IMAGE ├── Use specific tags, never :latest in production ├── Prefer slim/alpine variants (debian-slim > ubuntu > debian) ├── Pin digest for reproducibility in CI: image@sha256:... └── Match base to runtime needs (don't use python:3.12 for a compiled binary) LAYER OPTIMIZATION ├── Combine related RUN commands with && \ ├── Order layers: least-changing first (deps before source code) ├── Clean package manager cache in the same RUN layer ├── Use .dockerignore to exclude unnecessary files └── Separate build deps from runtime deps BUILD CACHE ├── COPY dependency files before source code (package.json, requirements.txt, go.mod) ├── Install deps in a separate layer from code copy ├── Use BuildKit cache mounts: --mount=type=cache,target=/root/.cache └── Avoid COPY . . before dependency installation MULTI-STAGE BUILDS ├── Stage 1: build (full SDK, build tools, dev deps) ├── Stage 2: runtime (minimal base, only production artifacts) ├── COPY --from=builder only what's needed └── Final image should have NO build tools, NO source code, NO dev deps- Generate optimized Dockerfile
- Apply all relevant optimizations
- Add inline comments explaining each decision
- Report estimated size reduction
- Validate
python3 scripts/dockerfile_analyzer.py Dockerfile
/docker:compose — Docker Compose Configuration
- Identify services
- Application (web, API, worker)
- Database (postgres, mysql, redis, mongo)
- Cache (redis, memcached)
- Queue (rabbitmq, kafka)
- Reverse proxy (nginx, traefik, caddy)
Apply compose best practices
SERVICES ├── Use depends_on with condition: service_healthy ├── Add healthchecks for every service ├── Set resource limits (mem_limit, cpus) ├── Use named volumes for persistent data └── Pin image versions NETWORKING ├── Create explicit networks (don't rely on default) ├── Separate frontend and backend networks ├── Only expose ports that need external access └── Use internal: true for backend-only networks ENVIRONMENT ├── Use env_file for secrets, not inline environment ├── Never commit .env files (add to .gitignore) ├── Use variable substitution: ${VAR:-default} └── Document all required env vars DEVELOPMENT vs PRODUCTION ├── Use compose profiles or override files ├── Dev: bind mounts for hot reload, debug ports exposed ├── Prod: named volumes, no debug ports, restart: unless-stopped └── docker-compose.override.yml for dev-only config- Generate compose file
- Output docker-compose.yml with healthchecks, networks, volumes
- Generate .env.example with all required variables documented
- Add dev/prod profile annotations
/docker:security — Container Security Audit
Dockerfile audit
Check Severity Fix Running as root Critical Add USER nonrootafter creating userUsing :latest tag High Pin to specific version Secrets in ENV/ARG Critical Use BuildKit secrets: --mount=type=secretCOPY with broad glob Medium Use specific paths, add .dockerignore Unnecessary EXPOSE Low Only expose ports the app uses No HEALTHCHECK Medium Add HEALTHCHECK with appropriate interval Privileged instructions High Avoid --privileged, drop capabilitiesPackage manager cache retained Low Clean in same RUN layer Runtime security checks
Check Severity Fix Container running as root Critical Set user in Dockerfile or compose Writable root filesystem Medium Use read_only: truein composeAll capabilities retained High Drop all, add only needed: cap_drop: [ALL]No resource limits Medium Set mem_limitandcpusHost network mode High Use bridge or custom network Sensitive mounts Critical Never mount /etc, /var/run/docker.sock in prod No log driver configured Low Set logging:with size limits- Generate security report
SECURITY AUDIT — [Dockerfile/Image name] Date: [timestamp] CRITICAL: [count] HIGH: [count] MEDIUM: [count] LOW: [count] [Detailed findings with fix recommendations]
Tooling
scripts/dockerfile_analyzer.py
CLI utility for static analysis of Dockerfiles.
Features:
- Layer count and optimization suggestions
- Base image analysis with size estimates
- Anti-pattern detection (15+ rules)
- Security issue flagging
- Multi-stage build detection and validation
- JSON and text output
Usage:
# Analyze a Dockerfile
python3 scripts/dockerfile_analyzer.py Dockerfile
# JSON output
python3 scripts/dockerfile_analyzer.py Dockerfile --output json
# Analyze with security focus
python3 scripts/dockerfile_analyzer.py Dockerfile --security
# Check a specific directory
python3 scripts/dockerfile_analyzer.py path/to/Dockerfilescripts/compose_validator.py
CLI utility for validating docker-compose files.
Features:
- Service dependency validation
- Healthcheck presence detection
- Network configuration analysis
- Volume mount validation
- Environment variable audit
- Port conflict detection
- Best practice scoring
Usage:
# Validate a compose file
python3 scripts/compose_validator.py docker-compose.yml
# JSON output
python3 scripts/compose_validator.py docker-compose.yml --output json
# Strict mode (fail on warnings)
python3 scripts/compose_validator.py docker-compose.yml --strictMulti-Stage Build Patterns
Pattern 1: Compiled Language (Go, Rust, C++)
# Build stage
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app/server ./cmd/server
# Runtime stage
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]Pattern 2: Node.js / TypeScript
# Dependencies stage
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production=false
# Build stage
FROM deps AS builder
COPY . .
RUN npm run build
# Runtime stage
FROM node:20-alpine
WORKDIR /app
RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001
COPY --from=builder /app/dist ./dist
COPY --from=deps /app/node_modules ./node_modules
COPY package.json ./
USER appuser
EXPOSE 3000
CMD ["node", "dist/index.js"]Pattern 3: Python
# Build stage
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt
# Runtime stage
FROM python:3.12-slim
WORKDIR /app
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
COPY --from=builder /install /usr/local
COPY . .
USER appuser
EXPOSE 8000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]Base Image Decision Tree
Is it a compiled binary (Go, Rust, C)?
├── Yes → distroless/static or scratch
└── No
├── Need a shell for debugging?
│ ├── Yes → alpine variant (e.g., node:20-alpine)
│ └── No → distroless variant
├── Need glibc (not musl)?
│ ├── Yes → slim variant (e.g., python:3.12-slim)
│ └── No → alpine variant
└── Need specific OS packages?
├── Many → debian-slim
└── Few → alpine + apk addProactive Triggers
Flag these without being asked:
- Dockerfile uses :latest → Suggest pinning to a specific version tag.
- No .dockerignore → Create one. At minimum:
.git,node_modules,__pycache__,.env. - COPY . . before dependency install → Cache bust. Reorder to install deps first.
- Running as root → Add USER instruction. No exceptions for production.
- Secrets in ENV or ARG → Use BuildKit secret mounts. Never bake secrets into layers.
- Image over 1GB → Multi-stage build required. No reason for a production image this large.
- No healthcheck → Add one. Orchestrators (Compose, K8s) need it for proper lifecycle management.
- apt-get without cleanup in same layer →
rm -rf /var/lib/apt/lists/*in the same RUN.
Installation
One-liner (any tool)
git clone https://github.com/alirezarezvani/claude-skills.git
cp -r claude-skills/engineering/docker-development ~/.claude/skills/Multi-tool install
./scripts/convert.sh --skill docker-development --tool codex|gemini|cursor|windsurf|openclawOpenClaw
clawhub install cs-docker-developmentRelated Skills
- senior-devops — Broader DevOps scope (CI/CD, IaC, monitoring). Complementary — use docker-development for container-specific work, senior-devops for pipeline and infrastructure.
- senior-security — Application security. Complementary — docker-development covers container security, senior-security covers application-level threats.
- autoresearch-agent — Can optimize Docker build times or image sizes as measurable experiments.
- ci-cd-pipeline-builder — Pipeline construction. Complementary — docker-development builds the containers, ci-cd-pipeline-builder deploys them.
Other versions7 projects use a version of this.
Word for word · 3
- Hassaan146/claude-skills★ 18100% same
- csiddhant796-blip/claude-skills-collection★ 2100% same
- mahiunfiltered/claude-code-skills★ 1100% same
Edited · 1
- Hussain-Elfalah/Agentic-Skills★ 274% same
Wrote their own version · 3
- JMBeresford/retrom★ 2.1ksame name
- mmtaee/ocserv-dashboard★ 275same name
- netresearch/docker-development-skill★ 24same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- skills/agenthub/CLAUDE.mdCLAUDE.md
- skills/autoresearch-agent/CLAUDE.mdCLAUDE.md
- agent-designerSkill
- agenthubSkill
- agent-workflow-designerSkill
- api-design-reviewerSkill
- api-test-suite-builderSkill
- autoresearch-agentSkill
- browser-automationSkill
- changelog-generatorSkill
- ci-cd-pipeline-builderSkill
- codebase-onboardingSkill
- database-designerSkill
- database-schema-designerSkill
- dependency-auditorSkill
- env-secrets-managerSkill
- everything-claude-code-conventionsSkill
- focused-fixSkill
- git-worktree-managerSkill
- helm-chart-builderSkill
- interview-system-designerSkill
- mcp-server-builderSkill
- migration-architectSkill
- monorepo-navigatorSkill
- observability-designerSkill
- performance-profilerSkill
- pr-review-expertSkill
- rag-architectSkill
- release-managerSkill
- runbook-generatorSkill
- secrets-vault-managerSkill
- engineering-advanced-skillsSkill
- skill-security-auditorSkill
- skill-testerSkill
- spec-driven-workflowSkill
- sql-database-assistantSkill
- tech-debt-trackerSkill
- terraform-patternsSkill
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.

