Compose, Break, Repeat

docker network rm -f and docker context rm -f share a flag name and do different things. docker network rm --help says its -f means “Do not error if the network does not exist”: a network still attached to a running container survives it regardless. docker context rm --help says its own -f means “Force the removal of a context in use”: on a context, -f genuinely forces removal even while it’s the active one. Both commands describe their own behavior accurately. The trap is assuming -f means the same thing everywhere because it’s the same letter, and skipping the one --help you actually needed to read. docker-destructive-guardrails, the skill this closing post covers, exists for exactly this kind of inconsistency: the places where “it looked like the other command” is how damage happens. ...

An agent that only describes a plan instead of executing it isn’t a model problem. It’s usually missing the one tool it needs to act, and the fix is a single line in agent.yaml: type: shell or type: todo. That’s the kind of symptom Docker Agent is built to catch. Docker Agent (the CLI is docker agent, built on the open-source cagent engine) lets you define an AI agent, its model, its instructions, the tools it can call, optionally a whole team of sub-agents delegating to each other, in a single YAML file instead of application code, then run, serve, or publish that file the same way you’d run, serve, or publish a container image. See the Docker Agent documentation for the full product picture. docker-agent-config, docker-agent-run, and docker-agent-deploy, the three skills this post covers, take that file from authoring through production. ...

One command, sbx run claude ., and Claude gets a complete, disposable place to work: its own filesystem, its own network, its own Docker daemon, built from the current directory in a few seconds, instead of running directly on your machine with your own shell, your own files, and your own network access. That’s Docker Sandboxes: a standalone sbx CLI that runs an AI coding agent inside an isolated microVM so a runaway command, a bad rm, or a prompt-injected instruction stays contained to a disposable environment instead of your actual laptop. See the Docker Sandboxes documentation for the full product picture; docker-sandboxes-lifecycle and docker-sandboxes-network-credentials, the two skills this post covers, are what make that sandbox practical to drive day to day: how isolated the agent’s workspace is, how you get back into a sandbox you left running, and exactly what it can reach on the network and authenticate with. ...

depends_on only guarantees a container has started. It says nothing about whether the process inside is actually ready to take traffic, and a database container that’s up but still replaying its init scripts will happily accept a connection from a service that then fails on its first query. docker-compose-patterns, the skill that fires when the task is service wiring rather than image builds, spends a good part of its rules closing that exact gap. ...

A registry token passed through ARG never shows up in docker run, never gets printed by the app, looks completely invisible. It’s still sitting in the image’s layer history, one docker history away from anyone who pulls it. That’s the exact mistake docker-build-strategies is written to intercept, and it’s one of several the Dockerfile & Build family of Docker Skills, covered here alongside docker-project-foundations, catches before the image ships. Part 1 introduced Docker Skills and the eleven skills it ships. The two skills in this post are deliberately scoped apart: docker-project-foundations handles the case where there’s no Docker setup at all yet, and steps aside once a project has a mature one that only needs minor edits; docker-build-strategies optimizes and hardens an existing Dockerfile, and steps aside when the actual need is that first-pass scaffold, or when the task is really about Compose wiring rather than image internals. Part 3 covers that Compose wiring skill next. ...