Docker Dev Environment

Quick Start

Use this skill when the user asks to create or standardize a Docker or Docker Compose setup, achieve local/repo parity for a containerized dev environment, or to debug, monitor, or validate dev containers locally and in CI.

Flow: (1) Detect existing Docker artifacts. (2) Choose minimal setup (Dockerfile-only vs Compose). (3) Ensure local and repo config stay in parity. (4) When preparing env or running build/up: tear down all Docker API envs first—remove the named container win-podiums-com-container (from any worktree), then docker compose down, then build and up so only one API container runs (see §3a). (5) Prepare env also includes building and deploying the SimHub plugin (see §3c): actively stop SimHub (Stop-Process), verify it is closed (Get-Process; do not proceed until zero SimHub processes), then build and copy the plugin to the SimHub install root. (6) Use container name win-podiums-com-container in Compose so the same name is used everywhere. (7) Provide run/debug/monitor workflows and verify them. (8) Define local and CI tests for Docker stability.

ContextStream (when available): Before changing Docker/Compose, use ContextStream search for "Docker", "compose", "wrangler", "Worker" to find existing setup and parity decisions. After Docker/parity decisions, capture in ContextStream (event_type=decision) with path to Dockerfile, compose.yaml, or docs/guides/development.md.

Scope

• In scope: Dockerfile and Docker Compose creation, local/repo config parity, execution (build/run), debugging (shell, logs, env, networks), monitoring (stats, state, disk, cleanup), and validation in CI.
• Out of scope: Production orchestration (e.g. Kubernetes) unless the user explicitly asks; image registry publishing; non-Docker dev environments. For change control and secrets in repo config, see github-change-control skill.

Best-Practices Sources

When creating or updating Dockerfile and Compose files, consult official Docker documentation as the standard: