/docker-development

name: "docker-development"
description: "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."
license: MIT
metadata:
  version: 1.0.0
  author: Alireza Rezvani
  category: engineering
  updated: 2026-03-16

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

1. **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

2. **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

3. **Generate optimized Dockerfile**

• Apply all relevant optimizations
• Add inline comments explaining each decision
• Report estimated size reduction

4. **Validate**

   python3 scripts/dockerfile_analyzer.py Dockerfile

`/docker:compose` — Docker Compose Configuration

1. **Identify services**

• Application (web, API, worker)
• Database (postgres, mysql, redis, mongo)
• Cache (redis, memcached)
• Queue (rabbitmq, kafka)
• Reverse proxy (nginx, traefik, caddy)

2. **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

3. **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

1. **Dockerfile audit**

| Check | Severity | Fix | |-------|----------|-----| | Running as root | Critical | Add `USER nonroot` after creating user | | Using :latest tag | High | Pin to specific version | | Secrets in ENV/ARG | Critical | Use BuildKit secrets: `--mount=type=secret` | | COPY 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 capabilities | | Package manager cache retained | Low | Clean in same RUN layer |

2. **Runtime security checks**

| Check | Severity | Fix | |-------|----------|-----| | Container running as root | Critical | Set user in Dockerfile or compose | | Writable root filesystem | Medium | Use `read_only: true` in compose | | All capabilities retained