refactor-compose

Standardizing a docker-compose.yml means ordering service properties consistently (container_name, image, restart, environment, ports, volumes, networks, depends_on, healthcheck) and moving all configurable values into a grouped .env file. This skill applies that structure automatically to existing or new files.

Group variables by service: a Global Configuration block (GLOBAL_NAME, RESTART_POLICY, TIMEZONE, healthcheck settings), then per-service blocks like Postgres Configuration and each app's Configuration with container name, image name, version, and ports. Add English comments labeling each group.

Name services after their technology (nginx, postgres), replacing spaces with underscores (uptime_kuma). Set container_name to {service}_app for web services, {service}_db for databases, and {service}_{tech} otherwise. Networks and volumes follow {SERVICE_CONTAINER_NAME}_network and _data patterns.

Prefer a stable release one version behind the newest when available; otherwise use latest or an explicit version. Always specify images with a fully qualified image name (FQIN) to avoid ambiguity when multiple registries are configured.

Yes. If you only provide service names or a tech stack, it generates a new docker-compose.yml and .env from the standard template without asking follow-up questions. Existing files are refactored against every rule instead.

Hardcoding defaults in docker-compose.yml splits configuration across two places and causes drift between environments. This skill forces all values into the .env file so the compose file stays a pure template and each environment is controlled by its own .env.