/vibe-ship

name: vibe-ship
description: Generates and audits production-ready deployment setups for any app. Detects the stack from the repo (Node/Next.js/Bun/Deno, Python/Django/FastAPI, Go, Rust, Java/Spring, .NET, Ruby/Rails, PHP/Laravel, Elixir/Phoenix, static sites, monorepos) and writes hardened Dockerfiles, .dockerignore, compose.yaml with databases/caches/queues, .env.example, GitHub Actions or GitLab CI (test, build, scan, SBOM, signing, deploy), Kubernetes manifests, and configs for Fly.io, Render, Railway, Cloud Run, AWS, Azure, VPS+Caddy or Kamal. Verifies output with a 90+ rule static auditor (score, SARIF, CI exit codes) and real docker builds. Use when the user says "dockerize", "containerize", "deploy this", "production-ready", "vibe ship this", "add CI/CD", "write a Dockerfile/docker-compose", "deploy to Fly/Render/Cloud Run/ECS/Kubernetes/a VPS", or wants an existing Dockerfile, compose file, pipeline or K8s manifest reviewed, audited or fixed, even for one file.

vibe-ship

Turns any codebase into something you can ship: hardened containers, a wired-up stack, a CI/CD pipeline, and the target platform's config. Every claim is backed by detection output, the audit score, and (when Docker is available) a real build and health check.

Scripts live in this skill's `scripts/` directory. They are standard-library Python 3.8+ with no installs. Invoke them as `python3 <skill-dir>/scripts/<name>.py`, or with `python` / `py -3` on Windows.

| Script | Purpose | |---|---| | `detect.py --path <repo> --json` | Evidence: services, stack, versions, ports, entrypoints, backing services, env vars, existing deploy files | | `audit.py --path <repo>` | 90+ rules across Dockerfile, .dockerignore, Compose, GitHub Actions, GitLab CI, Kubernetes. Score, grade, `--format sarif\|json\|markdown`, `--fail-on high` | | `pin_actions.py .github/workflows` | Pins every `uses:` to a commit SHA (`# vX.Y.Z` comment kept) via `git ls-remote` |

Pick the mode

| The user wants... | Mode | |---|---| | deployment files that don't exist yet | **Generate** | | an opinion on existing files ("review", "audit", "is this secure", "score my Dockerfile") | **Audit** | | existing files improved ("fix", "harden", "make this production-ready" when files exist) | **Fix** (Audit, then apply) | | to go live on a specific platform | **Target** (Generate or reuse the image, then add the platform layer) |

If `detect.py` reports existing Dockerfile/compose/CI and the user didn't explicitly ask to regenerate, use Audit or Fix. **Never overwrite an existing deployment file without saying so first.**

---

Generate

1. Detect (evidence, not guesses)

python3 <skill-dir>/scripts/detect.py --path . --json

Read the result before anything else:

• `services[]` are what gets a Dockerfile. `packages[]` are libraries and workspace roots that don't.
• Per service: `language`, `framework`, `kind` (web/worker/static), `package_manager` + `lockfile`, `runtime_version` + `version_source`, `port`, `entrypoint`, `build_cmd`, `health_path`, `backing_services`, `workers`, `migrations`, `env_vars`, `notes`.
• `monorepo`: build with the repo root as context.
• `existing`: deployment files already present. `git.image_ref` is the GHCR image name.
• `warnings`: each one becomes either a question to the user or a DEPLOYMENT.md item.

If `services` is empty, or a framework/entrypoint is missing for a web service, **ask**. A wrong base image or start command is worse than none. If `detect.py` can't run, inspect the manifests by hand using the same checklist.

2. Decide the target (one short question at most)

The defaults need no question: **Docker Compose for local and single-server, GitHub Actions, and GHCR.** Ask only when the answer changes files and the user didn't say:

• **Where will it run?** VPS (Compose + Caddy, or Kamal), Fly.io, Render, Railway, Heroku, DigitalOcean, Cloud Run, AWS App Runner/ECS, Azure Container Apps, or Kubernetes.
• **Registry**, only if not GHCR, and **GitLab CI** if `.gitlab-ci.yml` exists or the remote is GitLab.

In a non-interactive context, use the defaults and state them in the summary.

3. Load only the references you need

| Need | Read | |---|---| | Dockerfile for each service | `references/stacks/<runtime>.md`: `node` (Node/Bun/Deno), `python`, `go`, `rust`, `jvm`, `dotnet`, `ruby`, `php`, `elixir` (BEAM/Gleam), `static` (SPA/SSG), `other` (Swift/Dart/Haskell/Crystal/Zig/C++/...) | | Versions when the project declares none | `references/versions.md` | | Postgres/MySQL/Mongo/Redis/RabbitMQ/Kafka/Elastic/... in compose | `references/services.md` | | TLS, reverse proxy, app-server tuning, signals, trusted proxies | `references/servers.md` | | Platform config + deploy job | `references/deploy-targets.md` | | Pipelines (GitHub, GitLab, others) + Dependabot | `references/cicd-patterns.md` | | Kubernetes / Helm / Kustomize | `references/kubernetes.md` | | Final review | `references/security-checklist.md`, `references/scalability-checklist.md`, `references/anti-patterns.md` |

The templates are verified starting points. Adapt them to the detected entrypoint, port, package manager, and versions, and delete lines that don't apply (an asset stage with no frontend, a `public/` copy when there's no `public/`).

4. Write the files

| File | Contents | |---|---| | `Dockerfile` (one per service; monorepo: `apps/<svc>/Dockerfile`) | Multi-stage, pinned base, cache mounts, non-root, exec-form CMD, HEALTHCHECK with a tool that **exists in the final image** | | `.dockerignore` | Stack baseline + `.git`, `.env*` (`!.env.example`), build output | | `compose.yaml` | App + workers + detected backing services from `services.md`, healthchecks, `depends_on: condition: service_healthy`, one-off `migrate` service, named volumes, limits, restart, log rotation, no DB ports published | | `compose.override.yaml` (optional) | Dev-only: source bind mounts, DB ports on `127.0.0.1`, dev command | | `.env.example`