onboarding
The onboarding skill delivers a warm, guided welcome to new Nixopus users by loading the github-onboarding skill first, then greeting the user and directing them to connect their GitHub account. Use this when a new user triggers the __ONBOARD__ signal and has no existing GitHub connectors or deployed applications. The skill adapts its instructions for cloud-managed or self-hosted instances and provides the correct GitHub App installation link or dashboard path without inventing navigation steps.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/onboarding && cp -r /tmp/onboarding/api/skills/onboarding ~/.claude/skills/onboardingSKILL.md
# Onboarding
This skill is triggered when you receive a message containing exactly `__ONBOARD__`.
## What to do
**Step 1 — Load the github-onboarding skill immediately:**
```
read_skill("github-onboarding")
```
You MUST call this before composing your response. The github-onboarding skill contains the correct, authoritative steps for connecting GitHub (including the right links and flows for cloud vs self-hosted). Do not guess or invent navigation paths.
**Step 2 — Compose a single welcome response that includes:**
1. A brief greeting (one sentence). Plain text only, no emojis, no markdown headers.
2. One sentence explaining what Nixopus is: a platform where you describe what you want to deploy and it handles the rest, delivering a live URL.
3. The GitHub connection steps from the github-onboarding skill — use the correct flow for the user's instance type:
- **Cloud (managed Nixopus):** Direct them to install the GitHub App at the link provided in github-onboarding. The install link format is `https://github.com/apps/{appSlug}/installations/new`. Include this as a clickable link.
- **Self-hosted:** Direct them to the Apps page (`/apps`) in their Nixopus dashboard. The setup wizard there will create a GitHub App automatically via the manifest flow.
4. Tell them to come back after connecting so you can list their repos and deploy.
## Rules
- Do NOT call any other tools in this response — only `read_skill("github-onboarding")` to get accurate steps.
- Do NOT invent navigation paths like "Settings → Integrations → GitHub" — this does not exist.
- Do NOT ask questions in the first response — just greet and give the next step.
- Keep the total response to 4-6 sentences.
- The [user-context] block ALWAYS contains `instance: mode=cloud` or `instance: mode=self-hosted`. Use it directly. NEVER ask the user which one they are on.
- If mode is "cloud": give the GitHub App install link.
- If mode is "self-hosted": direct them to the Apps page (`/apps`).
## After the user returns
Once the user says they've connected GitHub (or comes back), call `get_github_connectors` to verify, then proceed with listing repositories and guiding the first deployment.Reference for all Nixopus API operations callable via nixopus_api(method, path, body)
Generate Caddyfile configurations for static sites and reverse proxies — SPA fallback routing, cache headers, compression, redirects, and error pages. Use when deploying a static site that needs custom Caddy configuration, or when the user needs SPA routing, caching, or redirect rules.
Generate docker-compose.yml for multi-service setups including databases, caches, and service dependencies. Use when the app needs a database, cache, message broker, or has multiple independently deployable services.
Size container memory and CPU limits, diagnose OOM kills and CPU throttling, and recommend resource adjustments by ecosystem. Use when containers are being OOM-killed, running slowly, or when setting initial resource limits for a deployment.
Build and deploy C/C++ applications — CMake, Meson, Ninja, and Dockerfile patterns. Use when deploying a C or C++ project, or when CMakeLists.txt or meson.build is detected.
Run database migrations safely during deployment — framework-specific commands, pre-deploy vs post-deploy timing, health gates, and rollback strategies. Use when the app has a database migration system and needs migrations run during deployment.
Build and deploy Deno applications — version detection, dependency caching, and Dockerfile patterns. Use when deploying a Deno project, or when deno.json or deno.jsonc is detected.
Sub-agent routing table — which agent handles diagnostics, machine health, infrastructure, GitHub, billing, and notifications. Load when the current task is not a direct deployment.