From corgi
Authors corgi-compose.yml files, runs and debugs corgi projects for multi-service setups with Docker databases, repo cloning, env generation, and tool checks via Go CLI.
npx claudepluginhub andriiklymiuk/corgi --plugin corgiThis skill uses the workspace's default tool permissions.
Corgi (https://github.com/Andriiklymiuk/corgi) runs multi-service projects from a single `corgi-compose.yml`. It handles: cloning service repos, starting databases in Docker, seeding from dumps, generating `.env` files with cross-service URLs, and running all services concurrently.
Generates docker-compose.yml files for multi-container apps with services, networks, volumes, health checks, resource limits, and environment overrides for dev/prod.
Guides Docker Compose configuration for multi-container apps including services, networking, volumes, health checks, environment variables, and CLI commands. Use for local orchestration of app, DB, cache, queues.
Generates Docker Compose files and configurations for containerized applications. Provides step-by-step guidance, best practices, and validation for DevOps containerization tasks.
Share bugs, ideas, or general feedback.
Corgi (https://github.com/Andriiklymiuk/corgi) runs multi-service projects from a single corgi-compose.yml. It handles: cloning service repos, starting databases in Docker, seeding from dumps, generating .env files with cross-service URLs, and running all services concurrently.
When this skill activates, you are the expert on corgi. Do not fall back to generic docker-compose / npm advice if a corgi-compose.yml is present — corgi is the authoritative entry point for that project.
corgi run is long-runningcorgi run blocks indefinitely, streams logs, and has no --detach flag. Never run it synchronously — it will hang your shell. See references/long-running.md before invoking it.
Safe synchronous probes:
corgi doctor (alias check) — preflight: tools installed, Docker up, ports freecorgi status (aliases health, healthcheck) — post-run: TCP/HTTP probe each portBoth exit 0 on success, 1 on failure. Output is colored text, not JSON.
| Task | Read |
|---|---|
Writing a new corgi-compose.yml | references/yml-schema.md then references/db-drivers.md |
| Picking a db driver (port, image, env prefix) | references/db-drivers.md |
Adding healthCheck: to a service or db | references/healthchecks.md |
corgi doctor or corgi run failed | references/debugging.md |
| Explaining / choosing a CLI flag | references/commands.md |
Running corgi run inside an agent loop | references/long-running.md |
Load only what the task needs. Do not read every reference every time.
Fresh project from scratch: use the /corgi-new slash command, or: write corgi-compose.yml → corgi doctor → start corgi run in background → corgi status.
Existing repo with corgi-compose.yml: this file is the single source of truth for how services start. Do not invent npm run dev, docker compose up, or per-service shell commands — use corgi run. Look at db_services: to know what databases exist and at services: to know what service repos are expected.
User says "start the project" / "run the backend": check for corgi-compose.yml first (ls corgi-compose.yml or ls *.corgi-compose.yml). If present, corgi is the answer.
corgi run # start everything (long-running, background it)
corgi doctor # preflight
corgi status # health check
corgi init # scaffold db_services/ + cloned repos
corgi create # interactive yml editor
corgi clean -i db # stop+remove db containers (also: services, corgi_services, all)
corgi pull # git pull in every service dir
corgi version # show installed version
Full surface in references/commands.md.