Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/soulcodex/agentic/docker-compose-local-setupnpx skills add soulcodex/agentic --skill docker-compose-local-setupgit clone --depth 1 https://github.com/soulcodex/agenticWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00052 | $0.00702 |
| Opus 5 | $0.00026 | $0.00351 |
| Sonnet 5 | $0.00010 | $0.00140 |
| Haiku 4.5 | $0.00005 | $0.00070 |
Grade A, and why
docker-compose-local-setup scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Docker Compose Local Setup Skill
Set up or improve local multi-service orchestration with docker compose.
Step 1 — Model Local Services
Define the local stack in compose.yaml:
- app services (API, worker, frontend)
- stateful dependencies (database, cache, broker)
- one-off jobs (migrations, seeds)
Keep local concerns explicit and avoid production-only orchestration details.
Step 2 — Configure Build, Runtime, and Networking
For each service:
- Use
build:for local image workflows orimage:when fixed images are preferred. - Set deterministic
container_nameonly when needed for tooling compatibility. - Map ports required for local access.
- Use the default compose network unless isolation is required.
Step 3 — Add Health Checks and Readiness
For services that others depend on:
- Add
healthcheck:with realistic command, interval, timeout, retries, and start period. - Prefer
depends_onwithcondition: service_healthywhere supported by your compose implementation. - If condition-based readiness is unavailable, add explicit wait logic in dependent services.
Step 4 — Manage Configuration and Secrets for Local Use
- Use
env_file:for shared local defaults. - Keep per-service overrides in
environment:. - Commit only safe sample files such as
.env.example. - Never hardcode credentials in
compose.yamlor checked-in env files.
Step 5 — Persist Data and Source Mounts
- Use named volumes for database/cache durability across restarts.
- Use bind mounts for hot-reload source workflows when appropriate.
- Keep mount paths narrow to avoid accidental host pollution.
Step 6 — Handle Migrations and Seed Data
Define one-off jobs for schema and seed flows:
- migration service/command that runs after dependencies are healthy
- optional seed service for local fixtures
- idempotent commands so repeated local setup is safe
Step 7 — Verify End-to-End Startup
Run and validate:
docker compose up --build -ddocker compose psdocker compose logs --tail=200- service-specific checks (HTTP health endpoint, DB connectivity)
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 95 lines · 52 tokens per session scan A 4dc25265677c
docker-compose-local-setup is a skill published in the GitHub repository soulcodex/agentic (10 stars, last pushed 2d ago), licensed MIT. It adds 52 tokens to every session and 702 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
container-manager-kubernetes-operations
Full operational Kubernetes surface via the container-manager-mcp MCP server — workloads (pods/rollouts/StatefulSets/DaemonSets/ReplicaSets/Jobs/CronJobs), config (ConfigMaps/Secrets/Namespaces/CRDs/patch), networking (Ingress/native Services/NetworkPolicy/DNS), storage (PV/PVC/StorageClass/snapshots/CSI), RBAC…
container-manager-config-walkthrough
End-user setup guide for the container-manager-mcp MCP server — choosing CONTAINERMANAGERTYPE (docker/podman/kubernetes/multi), wiring .env / mcpconfig toggles, connecting remote Docker/Podman hosts via the tunnel-manager inventory versus remote Kubernetes clusters via kubeconfig contexts, and a first-run verification…
container-manager-kg-ingestion
Snapshot a host's Docker/Podman/Swarm inventory into the epistemic-graph knowledge graph as typed OWL nodes via the container-manager-mcp MCP server — containers, images, volumes, networks, swarm services and nodes, with their :usesImage / :runsOn / :builtFrom links. Use when the agent must record live container state…
container-manager-multi-context
Operate several container backends and contexts at once — Kubernetes, Docker, Podman, and Swarm — via the container-manager-mcp MCP server's cmmulticontext tool, with per-call backend/context selection and parallel fan-out across a configured pool of contexts. Use when the agent must compare, migrate between, or…
container-manager-podman-operations
Rootless Podman pod/kube operations via the container-manager-mcp MCP server — pods (create/list/stats/top/inspect/logs/stop/rm), Kubernetes YAML interop (generate/play kube), checkpoint/restore, pod-scoped networks and volumes, health checks, and system prune. Use when the agent must drive Podman pod-level workloads…
container-manager-lifecycle
Docker/Podman container and image lifecycle on local or remote hosts via the container-manager-mcp MCP server — list/inspect/stop/remove/exec containers, read logs, trace which container owns a port, pull/prune images, and run docker-compose stacks. Use when the agent must operate standalone (non-swarm) container…