vibe-ship

Name: vibe-ship
Author: sudais-khalid

18stars0forks

How to install vibe-ship?

sudais-khalid/vibe-ship/vibe-ship

$npx -y skills add sudais-khalid/vibe-ship --skill vibe-ship

Installs into the current project.

Summary

Generates a complete, production-ready deployment setup for any app in one pass -- Dockerfile, docker-compose.yml, .dockerignore, CI/CD (GitHub Actions), scalability config (health checks, resource limits, K8s on request), and security hardening (non-root user, secrets, dependenc

Files · 1

View on GitHub

SKILL.md

1	# vibe-ship
2
3	Turns any codebase into something that can be deployed with `docker compose up` and shipped through CI/CD with sane, hardened defaults - all generated in one pass, tailored to the actual project. You bring the vibe; this brings the infrastructure.
4
5	## Two modes
6
7	1. Generate (default) - no deployment files exist yet, or the user wants a fresh setup. Walk through the workflow below.
8	2. Audit - deployment files already exist and the user wants them reviewed/scored rather than replaced. Skip straight to "Audit an existing setup" below.
9
10	---
11
12	## Generate: Workflow
13
14	### 1. Detect the stack
15
16	Look for these signal files in the project root (and one level into common subfolders like `backend/`, `server/`, `api/`):
17
18	\| File found \| Stack \| Default port \| Start command \|
19	\|---\|---\|---\|---\|
20	\| `package.json` \| Node.js \| 3000 \| read `scripts.start` \|
21	\| `requirements.txt` / `pyproject.toml` \| Python \| 8000 \| detect Flask/FastAPI/Django \|
22	\| `go.mod` \| Go \| 8080 \| `go build` \|
23	\| `pom.xml` / `build.gradle` \| Java/Kotlin (JVM) \| 8080 \| detect Spring Boot / Gradle app \|
24	\| `Gemfile` \| Ruby \| 3000 \| detect Rails/Sinatra \|
25	\| `Cargo.toml` \| Rust \| 8080 \| `cargo build --release` \|
26	\| `composer.json` \| PHP \| 8000 \| detect Laravel/Symfony \|
27
28	If multiple signal files exist (e.g. a `frontend/` and `backend/` folder), treat it as a multi-service app - generate one Dockerfile per service plus a docker-compose.yml that wires them together.
29
30	If you can't confidently detect a stack, ask the user rather than guessing - a wrong Dockerfile base image is worse than no Dockerfile.
31
32	Also detect:
33	- Package manager (npm vs yarn vs pnpm, pip vs poetry vs uv) from lockfiles present.
34	- Database/cache dependencies (look for `pg`, `mongoose`, `redis`, `sqlalchemy`, etc. in dependency files) - these become services in docker-compose.yml.
35	- Existing `.env` or `.env.example` - never overwrite; read it to learn what env vars the app expects.
36	- Existing Dockerfile/CI config - if present, offer Audit mode instead of silently overwriting.
37
38	### 2. Read the relevant stack reference
39
40	Before writing the Dockerfile, read `references/docker-patterns.md` and jump to the section matching the detected stack. It has copy-ready multi-stage Dockerfile templates per language - adapt to the project's actual entry point, build command, and dependencies rather than pasting blind.
41
42	Also skim `references/anti-patterns.md` so the generated files avoid the common mistakes listed there by construction.
43
44	### 3. Generate the files
45
46	Write these into the project (paths relative to repo root unless multi-service):
47
48	1. `Dockerfile` - multi-stage build (build stage + slim runtime stage), non-root user, `HEALTHCHECK` instruction, pinned base image version.
49	2. `.dockerignore` - excludes `node_modules`, `.git`, `.env`, build artifacts, test files, etc. per stack.
50	3. `docker-compose.yml` - the app service plus any detected dependent services (postgres, redis, etc.) with named volumes, resource limits, a shared network, env vars from `.env`.
51	4. `.env.example` - every env var the app reads, with placeholder values and a comment on what each is for. Never put real secrets here.
52	5. `.github/workflows/ci-cd.yml` - see `references/cicd-patterns.md`. At minimum: install deps → lint → test → build Docker image → (on main branch) push to a registry, plus a dependency vulnerability scan step. Ask which registry (Docker Hub / GHCR / ECR / GCR) before filling in the push step - default to GHCR since it needs no extra secrets beyond `GITHUB_TOKEN`.
53	6. `DEPLOYMENT.md` - a short doc at the project root summarizing what was generated, how to run it locally (`docker compose up`), how CI/CD triggers, and a checklist of anything the user still needs to do manually.
54
55	For scalability and security specifics, read `references/scalability-checklist.md` and `references/security-checklist.md` before finalizing the Dockerfile and compose file - apply every relevant item, and note anything needing manual follow-up in `

People who liked this also viewed

6 picks

Type

vibe-ship

18stars0forks

View on GitHub

How to install vibe-ship?

sudais-khalid/vibe-ship/vibe-ship

$npx -y skills add sudais-khalid/vibe-ship --skill vibe-ship

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# vibe-ship
2
3	Turns any codebase into something that can be deployed with `docker compose up` and shipped through CI/CD with sane, hardened defaults - all generated in one pass, tailored to the actual project. You bring the vibe; this brings the infrastructure.
4
5	## Two modes
6
7	1. Generate (default) - no deployment files exist yet, or the user wants a fresh setup. Walk through the workflow below.
8	2. Audit - deployment files already exist and the user wants them reviewed/scored rather than replaced. Skip straight to "Audit an existing setup" below.
9
10	---
11
12	## Generate: Workflow
13
14	### 1. Detect the stack
15
16	Look for these signal files in the project root (and one level into common subfolders like `backend/`, `server/`, `api/`):
17
18	\| File found \| Stack \| Default port \| Start command \|
19	\|---\|---\|---\|---\|
20	\| `package.json` \| Node.js \| 3000 \| read `scripts.start` \|
21	\| `requirements.txt` / `pyproject.toml` \| Python \| 8000 \| detect Flask/FastAPI/Django \|
22	\| `go.mod` \| Go \| 8080 \| `go build` \|
23	\| `pom.xml` / `build.gradle` \| Java/Kotlin (JVM) \| 8080 \| detect Spring Boot / Gradle app \|
24	\| `Gemfile` \| Ruby \| 3000 \| detect Rails/Sinatra \|
25	\| `Cargo.toml` \| Rust \| 8080 \| `cargo build --release` \|
26	\| `composer.json` \| PHP \| 8000 \| detect Laravel/Symfony \|
27
28	If multiple signal files exist (e.g. a `frontend/` and `backend/` folder), treat it as a multi-service app - generate one Dockerfile per service plus a docker-compose.yml that wires them together.
29
30	If you can't confidently detect a stack, ask the user rather than guessing - a wrong Dockerfile base image is worse than no Dockerfile.
31
32	Also detect:
33	- Package manager (npm vs yarn vs pnpm, pip vs poetry vs uv) from lockfiles present.
34	- Database/cache dependencies (look for `pg`, `mongoose`, `redis`, `sqlalchemy`, etc. in dependency files) - these become services in docker-compose.yml.
35	- Existing `.env` or `.env.example` - never overwrite; read it to learn what env vars the app expects.
36	- Existing Dockerfile/CI config - if present, offer Audit mode instead of silently overwriting.
37
38	### 2. Read the relevant stack reference
39
40	Before writing the Dockerfile, read `references/docker-patterns.md` and jump to the section matching the detected stack. It has copy-ready multi-stage Dockerfile templates per language - adapt to the project's actual entry point, build command, and dependencies rather than pasting blind.
41
42	Also skim `references/anti-patterns.md` so the generated files avoid the common mistakes listed there by construction.
43
44	### 3. Generate the files
45
46	Write these into the project (paths relative to repo root unless multi-service):
47
48	1. `Dockerfile` - multi-stage build (build stage + slim runtime stage), non-root user, `HEALTHCHECK` instruction, pinned base image version.
49	2. `.dockerignore` - excludes `node_modules`, `.git`, `.env`, build artifacts, test files, etc. per stack.
50	3. `docker-compose.yml` - the app service plus any detected dependent services (postgres, redis, etc.) with named volumes, resource limits, a shared network, env vars from `.env`.
51	4. `.env.example` - every env var the app reads, with placeholder values and a comment on what each is for. Never put real secrets here.
52	5. `.github/workflows/ci-cd.yml` - see `references/cicd-patterns.md`. At minimum: install deps → lint → test → build Docker image → (on main branch) push to a registry, plus a dependency vulnerability scan step. Ask which registry (Docker Hub / GHCR / ECR / GCR) before filling in the push step - default to GHCR since it needs no extra secrets beyond `GITHUB_TOKEN`.
53	6. `DEPLOYMENT.md` - a short doc at the project root summarizing what was generated, how to run it locally (`docker compose up`), how CI/CD triggers, and a checklist of anything the user still needs to do manually.
54
55	For scalability and security specifics, read `references/scalability-checklist.md` and `references/security-checklist.md` before finalizing the Dockerfile and compose file - apply every relevant item, and note anything needing manual follow-up in `

People who liked this also viewed

6 picks

Type