@vibetocloud/mcp 1.0.0

package/skills/skills/vibetocloud-onboard/SKILL.md

@@ -0,0 +1,417 @@
+---
+name: vibetocloud-onboard
+description: "Onboard an existing application to vibetocloud: authenticate, set up git remote, scaffold docker-compose.yml if needed, configure secrets, and push code."
+---
+
+# Vibetocloud Onboard
+
+Announce at start: "I'm using vibetocloud-onboard to set up your project on vibetocloud."
+
+## Prerequisites
+
+The vibetocloud MCP server must be configured in Claude Code. If MCP tools are not available, tell the user to add the vibetocloud MCP server to their Claude Code settings first (see `skills/README.md` for setup instructions).
+
+---
+
+## Step 1 — Check existing auth
+
+Read `.vibetocloud/config.json` using the Read tool.
+
+- If the file exists and contains a non-empty `token` field: call `org_authenticate` with that token.
+  - If `org_authenticate` succeeds: skip to **Step 2**.
+  - If it fails (token expired): proceed to authenticate below.
+- If the file does not exist or `token` is empty: proceed to authenticate below.
+
+**Authenticate:**
+
+Use the AskUserQuestion tool with options `["Yes", "No"]` to ask:
+"Would you like to pre-approve all vibetocloud MCP tools so Claude Code stops asking for permission on every call?"
+
+**If Yes:** Read `~/.claude/settings.json` using the Read tool. Add `"mcp__vibetocloud__*"` to the `permissions.allow` array (create the `permissions` key and `allow` array if they don't exist). Write the updated file back. Tell the user: "vibetocloud tools pre-approved. You won't be prompted again."
+
+Use the AskUserQuestion tool with options `["Login", "Register"]` to ask:
+"Do you already have a vibetocloud account, or are you signing up for the first time?"
+
+**If Login:**
+
+Ask the user: "What is your email address?"
+
+Call `org_request_otp` with:
+```json
+{ "email": "<user email>" }
+```
+
+If the call fails, tell the user the error and stop.
+
+Tell the user: "A one-time code has been sent to your email. Please enter it."
+
+Ask the user for the code, then call `org_verify_otp` with:
+```json
+{ "email": "<user email>", "code": "<entered code>" }
+```
+
+If the call fails, tell the user the error and stop.
+
+**If Register:**
+
+Ask the user for:
+- Full name
+- Email address
+- Organisation name
+
+Call `org_register` with:
+```json
+{ "name": "<full name>", "email": "<email>", "orgName": "<org name>" }
+```
+
+If the call fails, tell the user the error and stop.
+
+Tell the user: "Account created! Sending a one-time code to verify your email."
+
+Call `org_request_otp` with:
+```json
+{ "email": "<user email>" }
+```
+
+If the call fails, tell the user the error and stop.
+
+Tell the user: "A one-time code has been sent to your email. Please enter it."
+
+Ask the user for the code, then call `org_verify_otp` with:
+```json
+{ "email": "<user email>", "code": "<entered code>" }
+```
+
+If the call fails, tell the user the error and stop.
+
+**After successful verify (both flows):**
+
+On success the response contains `{ token, userId, orgId, userName, orgName }`.
+
+Write `.vibetocloud/config.json` using the Write tool:
+```json
+{
+  "token": "<token from response>",
+  "orgId": "<orgId from response>",
+  "appId": "",
+  "environment": "",
+  "remote": ""
+}
+```
+
+Add `.vibetocloud/` to `.gitignore` — read the current `.gitignore` first, then append the line if it is not already present.
+
+Tell the user: "Welcome, <userName>! You're signed in to org <orgName>."
+
+---
+
+## Step 2 — App setup
+
+Call `app_list` with:
+```json
+{ "token": "<token>", "orgId": "<orgId>" }
+```
+
+Build an options list from the response: one option per existing app (label = app name), plus a final option `"Create new app"`.
+
+Use the AskUserQuestion tool with those options to ask:
+"Is this project already registered on vibetocloud, or should I create a new one?"
+
+**If an existing app is selected:** save its `id` as `appId` in `.vibetocloud/config.json`.
+
+**If "Create new app":** ask the user for a name (lowercase letters, numbers and hyphens only — suggest the current directory name lowercased with spaces replaced by hyphens). Call `app_create` with:
+```json
+{ "token": "<token>", "name": "<app name>", "orgId": "<orgId>" }
+```
+
+The response contains `{ id, name, gitUrl, ... }`. Save `id` as `appId` and `gitUrl` in `.vibetocloud/config.json`.
+
+Save `"dev"` as `environment` in `.vibetocloud/config.json`.
+
+---
+
+## Step 3 — Git remote
+
+Run the Bash tool:
+```bash
+git remote -v
+```
+
+**Case A — no remotes:** Run:
+```bash
+git remote add origin <gitUrl from config>
+```
+Save `"origin"` as `remote` in `.vibetocloud/config.json`. Tell the user: "vibetocloud set as origin."
+
+**Case B — `origin` exists pointing to an external host:**
+Run:
+```bash
+git remote add vibetocloud <gitUrl from config>
+```
+
+Use the AskUserQuestion tool with options `["Yes — make vibetocloud my new origin", "No — keep my current origin"]` to ask:
+"Your current origin points to an external host. Do you want to make vibetocloud your new origin? (Your current origin will be saved as `origin-backup`.)"
+
+If **Yes**:
+```bash
+git remote rename origin origin-backup
+git remote rename vibetocloud origin
+```
+Save `"origin"` as `remote` in `.vibetocloud/config.json`. Tell the user: "vibetocloud is now origin. Your previous origin is saved as origin-backup."
+
+If **No**: Save `"vibetocloud"` as `remote` in `.vibetocloud/config.json`. Tell the user: "All skill pushes will target the `vibetocloud` remote explicitly."
+
+---
+
+## Step 4 — docker-compose.yml
+
+Check whether `docker-compose.yml` or `compose.yaml` exists in the project root using the Read tool.
+
+**If found:** tell the user "Found docker-compose.yml." Continue to Step 5.
+
+**If not found:**
+
+Detect project type by checking for these files in order:
+1. `package.json` → Node.js
+2. `requirements.txt` or `pyproject.toml` → Python
+3. `Dockerfile` → custom image
+4. None of the above → use the AskUserQuestion tool with options `["Node.js", "Python", "Other (Dockerfile)"]` to ask: "What runtime does your application use?"
+
+Generate a `docker-compose.yml` appropriate for the detected type.
+
+**Node.js template:**
+```yaml
+services:
+  app:
+    build: .
+    ports:
+      - "3000:3000"
+    env_file:
+      - .env
+    environment:
+      - NODE_ENV=production
+    restart: unless-stopped
+```
+
+**Python template:**
+```yaml
+services:
+  app:
+    build: .
+    ports:
+      - "8000:8000"
+    env_file:
+      - .env
+    environment:
+      - PYTHONUNBUFFERED=1
+    restart: unless-stopped
+```
+
+**Custom image (has Dockerfile):**
+```yaml
+services:
+  app:
+    build: .
+    ports:
+      - "8080:8080"
+    env_file:
+      - .env
+    restart: unless-stopped
+```
+
+Show the generated file to the user and use the AskUserQuestion tool with options `["Looks good", "I want to make changes"]` to ask: "Does this docker-compose.yml look correct?"
+
+If **"I want to make changes"**: ask the user to describe the changes and update the file accordingly before writing.
+
+After confirmed, write `docker-compose.yml` using the Write tool.
+
+---
+
+## Step 5 — Pre-flight check
+
+Read `docker-compose.yml` (or `compose.yaml`) and run both checks before pushing.
+
+> **How secrets reach your containers:** at deploy time vibetocloud writes all configured secrets to a `.env` file in your app directory. Docker Compose loads this file automatically when each service declares `env_file: - .env`. This means you do **not** need `${VAR}` references in your compose file — just add `env_file: - .env` to each service and the variables will be available at runtime.
+
+If `docker-compose.yml` does not already have `env_file: - .env` on each service, tell the user and use the AskUserQuestion tool with options `["Yes — add it now", "No — I'll add it manually"]` to ask: "Would you like me to add `env_file: - .env` to your docker-compose.yml services now?"
+
+If Yes, add `env_file:\n  - .env` under each service in `docker-compose.yml`.
+
+Also check `.gitignore` for a `.env` entry. If missing, append it — the `.env` file is generated at deploy time and must never be committed.
+
+### Check 1 — Build method
+
+For each service, inspect the `image:` and `build:` keys.
+
+**Supported:**
+- `build: .` or `build: <path>` — builds from a local Dockerfile ✅
+- `image: <public-image>` with no `${...}` references and no private registry hostname ✅ (e.g. `redis:alpine`, `postgres:15`)
+
+**Not supported:**
+- `image:` containing `${...}` — image name uses an unresolved environment variable ❌
+- `image:` referencing a private registry — any URL containing `.dkr.ecr.`, `gcr.io`, `ghcr.io`, `azurecr.io`, or any hostname-style prefix ❌
+
+If any service uses an unsupported build method, **stop** and tell the user what was found, then use the AskUserQuestion tool with options `["Yes — create a Dockerfile", "No — I'll handle it myself"]` to ask:
+"vibetocloud cannot pull this image. Would you like me to create a Dockerfile so vibetocloud can build it directly?"
+
+If Yes, help them create a suitable Dockerfile and update the service in `docker-compose.yml` to use `build: .` instead. Then re-run both checks. If No, stop — do not push until this is resolved.
+
+### Check 2 — Unresolved environment variables
+
+Scan the full `docker-compose.yml` for `${VARIABLE_NAME}` patterns. Collect all unique variable names referenced.
+
+Remove from the list:
+- Variables that have an inline default in the compose file (`${VAR:-default}`)
+- Common platform-provided variables: `PORT`, `NODE_ENV`, `PYTHONUNBUFFERED`, `HOST`, `TZ`
+
+If any variables remain unaccounted for, tell the user which ones, then use the AskUserQuestion tool with options `["Yes — add them now", "No — continue anyway"]` to ask:
+"These environment variables are referenced in docker-compose.yml but not configured as secrets. The application may fail to start if they are required. Would you like to add them now?"
+
+If Yes, collect the values one at a time as `NAME=value`. For each, call `app_create_secret` with:
+```json
+{
+  "token": "<token>",
+  "applicationId": "<appId>",
+  "environment": "<environment>",
+  "name": "<NAME>",
+  "value": "<value>"
+}
+```
+Note: names must be uppercase with underscores (e.g. `DATABASE_URL`). Convert lowercase automatically.
+Tell the user: "⚠️ Secret values are encrypted and cannot be retrieved — make sure you have them saved elsewhere."
+
+If No, continue with a warning.
+
+### Check 3 — Environment variables used in application code
+
+Scan the source files for environment variable references using the Bash tool.
+
+**Determine the scan command based on the detected project type:**
+
+Node.js / TypeScript (`.js`, `.ts`, `.jsx`, `.tsx`):
+```bash
+grep -rh --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" \
+  --exclude-dir=node_modules --exclude-dir=dist --exclude-dir=build --exclude-dir=.next \
+  --exclude-dir=coverage --exclude-dir=.git \
+  -oP 'process\.env\.([A-Z0-9_]+)' . | sort -u
+```
+
+Python (`.py`):
+```bash
+grep -rh --include="*.py" \
+  --exclude-dir=__pycache__ --exclude-dir=.venv --exclude-dir=venv --exclude-dir=.git \
+  -oP '(?:os\.environ(?:\.get)?\(["\x27])([A-Z0-9_a-z]+)|(?:os\.getenv\(["\x27])([A-Z0-9_a-z]+)' . \
+  | grep -oP '[A-Z0-9_a-z]+$' | sort -u
+```
+
+If neither pattern yields results, skip this check.
+
+**Also check for dynamic references** (values that cannot be extracted):
+
+```bash
+grep -rn --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" \
+  --exclude-dir=node_modules --exclude-dir=dist --exclude-dir=build \
+  'process\.env\[' .
+```
+
+If any dynamic references are found, warn the user:
+> "⚠️ Your code contains dynamic environment variable references (e.g. `process.env[someVar]`) in the files listed above. These cannot be checked automatically — make sure any variables accessed this way are configured as secrets."
+
+**Build the list of variables found in code**, then remove:
+- Variables already added as secrets during Check 2
+- Variables with inline defaults in docker-compose (`${VAR:-default}`)
+- Common platform-provided variables: `PORT`, `NODE_ENV`, `PYTHONUNBUFFERED`, `HOST`, `TZ`, `PATH`, `HOME`, `USER`
+
+If any variables remain, tell the user which ones were found and in which files (re-run grep without `-h` to get filenames), then use the AskUserQuestion tool with options `["Yes — add them now", "No — continue anyway"]` to ask:
+"These environment variables are used in your application code but not configured as secrets. Would you like to add them now?"
+
+If Yes, collect the values one at a time as `NAME=value` and call `app_create_secret` for each (same call as in Check 2 above). Tell the user: "⚠️ Secret values are encrypted and cannot be retrieved — make sure you have them saved elsewhere." If No, continue with a warning.
+
+### Check 4 — NODE_ENV for Node.js apps
+
+If the project has a `package.json`, scan `docker-compose.yml` for `NODE_ENV=production`:
+
+```bash
+grep "NODE_ENV" docker-compose.yml 2>/dev/null || true
+```
+
+If `NODE_ENV=production` is not present in any service's `environment:` block, warn the user:
+
+> "⚠️ `NODE_ENV=production` is not set in your docker-compose.yml. Node.js apps often disable static file serving, enable production error handling, and trust proxies only when this variable is set. Without it your app may fail the health check or behave unexpectedly in production."
+
+Use the AskUserQuestion tool with options `["Yes — add it now", "No — I'll add it manually"]` to ask: "Would you like me to add `NODE_ENV=production` to your main app service?"
+
+If Yes, add `NODE_ENV=production` under the `environment:` key of the first service that has a `build:` directive in `docker-compose.yml`. If no `environment:` key exists on that service, add one.
+
+---
+
+### Check 5 — .dockerignore audit
+
+Check whether `.dockerignore` exists using the Read tool. If it does not exist, skip this check.
+
+If it exists, read it and flag any line that would exclude a file critical to the build. Dangerous patterns include:
+- `package.json`, `**/package.json`, or `*.json` globs at any path level
+- `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`
+- `requirements.txt`, `pyproject.toml`
+- `Dockerfile`
+
+For each flagged line, explain the risk. For example: "`client/*.json` would exclude `client/package.json` from the build context, causing any `COPY client/package.json` instruction in your Dockerfile to fail."
+
+Use the AskUserQuestion tool with options `["Yes — remove flagged lines", "No — I know what I'm doing"]` to ask: "These .dockerignore patterns may exclude files needed during the Docker build. Would you like me to remove them?"
+
+If Yes, remove the flagged lines from `.dockerignore` and write the file back using the Write tool.
+
+---
+
+If all checks pass with no issues, tell the user: "✅ Pre-flight check passed — build method is supported, environment variables are accounted for, and your Docker configuration looks clean."
+
+---
+
+## Step 6 — First push
+
+Stage and commit any newly created files:
+```bash
+git add -A
+git status
+```
+
+If there are uncommitted changes, run:
+```bash
+git commit -m "chore: add vibetocloud configuration"
+```
+
+Get the current branch:
+```bash
+git rev-parse --abbrev-ref HEAD
+```
+
+**If the current branch is not `main` or `master`:**
+
+Use the AskUserQuestion tool with options `["Yes — merge into main", "No — push this branch as-is"]` to ask:
+"You're on branch `<branch>`. vibetocloud deploys from `main`. Would you like to merge this branch into `main` now?"
+
+**If Yes:**
+```bash
+git checkout main
+git pull <remote from config> main --no-edit
+git merge <feature branch> --no-edit
+git push <remote from config> main
+```
+
+If any of these fail, show the error and ask the user to resolve it manually before continuing.
+
+Tell the user: "Branch merged. Deploying from `main`."
+
+**If No:** warn the user: "⚠️ You are pushing branch `<branch>` — remember to merge it into `main` before deploying, or deploy will target this branch."
+
+Push to the platform:
+```bash
+git push <remote from config> HEAD:<current branch>
+```
+
+If the push fails due to no upstream tracking branch, run:
+```bash
+git push --set-upstream <remote from config> <current branch>
+```
+
+Tell the user: "✅ Your code is on vibetocloud. Run `/vibetocloud-deploy` to trigger your first deployment."

package/skills/skills/vibetocloud-platform-logs/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: vibetocloud-platform-logs
+description: Access platform-level logs for the VibeToCloud platform itself (not a deployed app). Use when debugging the vibetocloud.io host, investigating platform-wide issues, or when the user mentions Grafana, the logging server, or needing an SSH tunnel to inspect logs.
+---
+
+# VibeToCloud Platform Logs
+
+Announce at start: "I'm using vibetocloud-platform-logs to access the platform Grafana logs."
+
+This skill is for debugging the **VibeToCloud platform itself** (the `vibetocloud.io` host).
+For debugging a *deployed application's* services, use `vibetocloud-debug` instead.
+
+---
+
+## Step 1 — Open the SSH tunnel
+
+Grafana runs on the `vibetocloud.io` host on port `3010` and is not exposed publicly.
+Open a local tunnel that forwards local port `3110` to it:
+
+```bash
+ssh -L 3110:localhost:3010 ubuntu@vibetocloud.io -fN
+```
+
+Notes:
+- `-fN` runs the tunnel in the background without opening a shell, so the command returns immediately.
+- If the command fails with "Address already in use", a tunnel is likely already open — proceed to Step 2.
+- This requires SSH access to `vibetocloud.io` as the `ubuntu` user.
+
+---
+
+## Step 2 — Open Grafana
+
+Once the tunnel is up, Grafana is reachable at:
+
+**http://localhost:3110/**
+
+Credentials:
+- Username: `admin`
+- Password: `change-me`
+
+Use the Explore / Logs views in Grafana to inspect platform logs.
+
+---
+
+## Step 3 — Close the tunnel (when done)
+
+The tunnel runs in the background. To close it when finished:
+
+```bash
+pkill -f "ssh -L 3110:localhost:3010"
+```