deploy-flow
# ClaudeWave Editor Entry Deploy-flow orchestrates end-to-end application deployment by detecting source type (GitHub, S3, or public URL), analyzing project hints (framework, port, Dockerfile), and routing to appropriate deployment tools. Use this skill when users request application deployment, providing source context detection, configuration analysis, and live URL delivery without requiring manual setup steps.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/deploy-flow && cp -r /tmp/deploy-flow/api/skills/deploy-flow ~/.claude/skills/deploy-flowSKILL.md
# Deploy Flow
## Sample App Fast Path
If a `[sample-app-fast-path]` block is injected in the system messages, follow it exactly. Do NOT load this skill or any other skill — the fast path already contains the complete recipe.
## Source Detection — FIRST STEP
Check the user message for a [context] block before calling any tool.
**Frontend context block** — `[Context: Repository "owner/repo" (Language: ..., Branch: ..., Visibility: public|private)]`:
- **Visibility: public** → first call `load_tool({ toolName: "load_remote_repository" })` (it is a searchable tool), then call `load_remote_repository` with `repoUrl: "https://github.com/owner/repo"` and the branch. Do NOT call `get_github_repositories` or `analyze_repository` — `load_remote_repository` already returns hints. Then continue the hints-driven deploy flow (step 2 below). Source and repository are set automatically.
- **Visibility: private** → the repo must be in connected GitHub repos. Check `[user-context]` for the numeric repo ID. If found, use the **standard GitHub flow** (routing step 1). If not found, ask the user to connect the repo.
**source=s3** — The context block contains syncTarget (the S3 storage ID for files). It may also contain applicationId if the app already exists.
- Call load_local_workspace with the syncTarget value. It returns `hints` with ecosystem, framework, port, Dockerfile presence, and confidence levels.
- If applicationId is present: the app exists. Use it for deploy_project (or quick_deploy if redeploying from scratch).
- If applicationId is absent: this is a first deploy. Use the returned hints to decide config, then quick_deploy (or createProject if you need to set env vars first). Source and repository are set automatically for S3.
- GitHub connector tools are blocked for S3 sources — do not attempt them.
**No context block** — Check `[user-context]` first — it has connectors, repos, apps, servers, and domains pre-loaded. Route from connector access and what the user asked for; do **not** treat missing GitHub connector as a hard stop if a public git URL can be used instead.
**Behavior checklist (routing expectations):**
- **Case A:** No connector + user provides a valid public HTTPS git URL → call `load_remote_repository` — it returns hints. Continue the hints-driven deploy flow.
- **Case B:** Connectors/repos available + user includes a URL in the message → default to the **standard GitHub flow** below (use connected repo access), unless the user **explicitly** asked to deploy from a pasted public URL instead of connected repos. **Explicit URL preference** means wording that clearly bypasses the connector for that deploy, for example: "deploy from this URL", "clone `https://github.com/org/repo.git` — don't use my connected repos", "ignore my GitHub connection and use this public repo link", "use the pasted HTTPS link, not my org's connected repositories".
- **Case C:** No connector + no valid public HTTPS git URL in the message → ask the user for a public HTTPS clone URL; you may optionally point them at `read_skill("github-onboarding")` as an alternative — onboarding is **not** a hard blocker.
**Routing (no `[context]` block, no frontend context block):**
1. **Connectors/repos available** (per `[user-context]`, or refresh with nixopus_api('get_github_repositories') / nixopus_api('get_applications') only if context is clearly stale — e.g. user says they just connected GitHub but `[user-context]` still shows no connectors; repo/app lists contradict what a fresh call returns; or the user reports an error about a resource that does not appear in context) **and** the user did **not** explicitly request deploying from a public git URL (connector bypass — see **Case B** examples above): **standard GitHub flow.** Use pre-loaded connector/repo IDs instead of redundant API calls when possible. Then: `analyze_repository` (returns hints) → use hints to decide config → `quick_deploy` or `createProject` + nixopus_api('deploy_project', { id }).
**Fallback (connector path failed, URL still viable):** If you already chose the standard GitHub flow but a required GitHub/connector step fails (auth, missing repo, permission, transient API error, etc.) **and** the user's message still contains a **valid public HTTPS git clone URL** you can use: switch to **`load_remote_repository`** with that URL (and branch if given), then continue the **hints-driven** deploy flow. Prefer this over repeatedly retrying the connector when the public URL is a known-good alternative. Connector-first ordering is unchanged: attempt the connector path first when the rules above apply; only fall back after a real failure.
2. **Connector/repo access missing** and the user provided a **valid public HTTPS git clone URL** (e.g. `https://github.com/org/repo.git` or `https://…/org/repo` — not `git@…` SCP-style, not non-HTTPS schemes): call **`load_remote_repository`** with that URL (and branch if the user specified one) — it returns hints. Then continue the **hints-driven** deploy flow: use hints to decide config, then `quick_deploy` or `createProject` / `deploy_project`.
3. **Connector/repo access missing** and **no** valid public HTTPS git URL is present: **ask** the user for a public HTTPS clone URL they can share. Optionally mention `read_skill("github-onboarding")` if they prefer to connect GitHub instead — do **not** refuse to continue the deploy solely because onboarding was skipped.
## Deploy Patterns
A [deploy-patterns] block may be injected with known fixes, pitfalls, and fast paths for the detected ecosystem. When present, check it before diagnosing issues — if a known fix matches, apply it directly instead of re-investigating from scratch.
## Deploy Steps
1. **Load codebase** — call ONE of: analyze_repository, load_remote_repository, or load_local_workspace. All three return a **hints** object. NEVER call more than one for the same repo — they are alternatives, not complements.
- `load_remote_repository` → public repReference 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.