agentsclimarketplace

Docker compose

Skill nbsp1221/agent-skills/skills/docker-compose

🧠 Personal collection of Agent Skills and instructions for AI agents

Install
npx -y skills add nbsp1221/agent-skills --skill docker-compose

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Write and review Docker Compose files with consistent best practices and conventions (file naming, override strategy, service naming, key ordering, env handling, ports, and healthchecks). Use when creating or standardizing compose.yaml/docker-compose.yml.

SKILL.md

3.7 KB, 805 tokens by cl100k_base, as published. Nobody here has run it

Docker Compose

Opinionated conventions for consistent, maintainable Docker Compose files.

Best Practices

File naming and override strategy

  • Prefer compose.yaml (or compose.yml) as the canonical base file.
  • Keep local-only changes in compose.override.yaml (auto-merged by Compose).
    • If an override file is local-only, add it to .gitignore unless the team explicitly wants it committed (optionally keep a .example file).
  • For environment-specific configs, use compose.<env>.yaml and combine with -f.
  • Avoid the top-level version key (obsolete).

Service naming and identity

  • Use kebab-case service names; they become internal DNS names.
  • Avoid container_name unless strictly required; it prevents scaling.
  • Pin image tags (avoid latest); prefer digests for production.

Env var conventions

  • Use .env for interpolation, env_file for container runtime values.
  • Keep secrets out of Compose files; commit .env.example only.
  • Prefer mapping style for environment when values include special chars.
  • If the same variable is set in both, environment overrides env_file (key order does not change behavior).

Ports, volumes, and paths

  • Quote HOST:CONTAINER port mappings to avoid YAML base-60 parsing issues.
  • Prefer relative bind mounts starting with ./.
  • Use named volumes for persistent data.

Readiness and dependencies

  • Use depends_on for ordering; add healthcheck and condition: service_healthy for readiness-sensitive dependencies.

Profiles for optional services

  • Use profiles to gate optional services (e.g., debug, seed, admin) instead of maintaining separate files.
  • If a service is profile-gated, any depends_on targets must be in the same profile or always enabled; otherwise the model is invalid.

Project naming and file composition

  • Set top-level name when you need stable project identifiers (network/volume names) across directories or CI.
  • Use include/fragments to split large Compose files, but only if your Compose implementation supports them.

DRY with extensions and anchors

  • Use x- extension fields plus YAML anchors/merge to share repeated blocks (env, volumes, labels) across services.

Secrets and configs

  • Declare secrets/configs at top level and explicitly grant access per service; top-level declaration alone is not enough.
  • Prefer secrets/configs for sensitive or shared files when the platform supports them.

Deploy portability

  • Treat deploy as platform-specific; some Compose implementations ignore it in local runs.
  • Document when deploy is required so users do not assume it applies everywhere.

Init for PID 1

  • Set init: true for long-running services to handle PID 1 signal and zombie reaping correctly.

Ordering Conventions

Top-level order

  1. name (optional)
  2. services
  3. networks
  4. volumes
  5. configs
  6. secrets

Service key order

Use this exact order for keys within each service to keep the file consistent.

  1. Identity: image / build, container_name, hostname
  2. Runtime: command, entrypoint, restart
  3. Environment: env_file, environment, labels
  4. Resources: ports, expose, volumes
  5. Connectivity: depends_on, networks, network_mode
  6. Health: healthcheck

Validation

  • Always run docker compose config before shipping changes.

References

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most containers cloud skills give in 805 tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildsin 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • use compose.yaml as the canonical base file
  • use kebab-case for service names
  • pin image tags
  • quote host-container port mappings
  • set init true for long-running services
  • order service keys consistently

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.