--- name: parallel-preview-orchestrator description: Orchestrate parallel preview-site creation across multiple CLI backends (`codex-cli`, `gemini-cli`, `deepseek-code`) and publish each result with `pipo-deploy`. Default routing is `/preview//`, but agent-specific runs may also publish to `///` when the human asks for that exact naming convention. metadata: {"openclaw":{"emoji":"🧪","requires":{"bins":["codex","gemini-cli","deepseek-code","pipo-deploy","python3"]}}} --- # Parallel Preview Orchestrator Use this skill when the human wants multiple backend-specific demos or preview sites at the same time. ## Default Execution Mode - In direct chat surfaces (especially Telegram), default to **background-first orchestration**. - The chat-facing agent should stay responsive: delegate the heavy work, report what was launched, and return control quickly. - In Telegram/direct chat, use **background process workers only** for this skill. Do not use `sessions_spawn` there. - Use one background worker per backend and keep the returned process handle / session ID for monitoring. - Persist worker state in `/home/ubuntu/.openclaw/workspace/ops/worker-status.md` so the human can inspect a stable status board. - Do **not** hold the main chat lane hostage for long-running builds unless the human explicitly asks to wait inline. ## Orchestration Model - The main agent is the orchestrator only. - Treat each backend run as a separate worker/subagent-style execution with isolated responsibility. - Use one worker for `codex-cli`, one worker for `gemini-cli`, and one worker for `deepseek-code`. - Each worker owns exactly one site: one folder, one port, one deploy name. - The orchestrator gathers results and reports the final URLs. ## Core Rules - Launch one execution per backend. Do not collapse the whole job into one giant shell command. - Use separate folders, separate ports, and separate deploy names. - Never publish to `/`. - Default preview path is `/preview//`. - If the human explicitly asks for an agent/site path convention, use `pipo-deploy /` so the final URL becomes `https://miopenclaw-vnic.tail9799d2.ts.net///`. - Do not claim success for any site until the backend ran and the deploy step ran. - If one backend fails, report which one failed and which ones succeeded. - The orchestration path for Telegram/direct chat is: - spawn three **background worker processes** and monitor them separately - return immediately with a concise launch/status message - Do not attempt `sessions_spawn` in Telegram/direct chat for this skill. ## Fixed Mapping For the standard 3-way demo flow, use: - `codex-cli` -> folder `preview-apps/codex-demo` -> port `3001` -> deploy name `codex-demo` - `gemini-cli` -> folder `preview-apps/gemini-demo` -> port `3002` -> deploy name `gemini-demo` - `deepseek-code` -> folder `preview-apps/deepseek-demo` -> port `3003` -> deploy name `deepseek-demo` Final URLs: - `https://miopenclaw-vnic.tail9799d2.ts.net/preview/codex-demo/` - `https://miopenclaw-vnic.tail9799d2.ts.net/preview/gemini-demo/` - `https://miopenclaw-vnic.tail9799d2.ts.net/preview/deepseek-demo/` For agent/site verification runs, this alternate mapping is also valid: - `codex` -> `https://miopenclaw-vnic.tail9799d2.ts.net/codex//` - `gemini` -> `https://miopenclaw-vnic.tail9799d2.ts.net/gemini//` - `deepseek-code` -> `https://miopenclaw-vnic.tail9799d2.ts.net/deepseek-code//` ## Workflow 1. Create the three target folders under `/home/ubuntu/.openclaw/workspace/preview-apps/`. 2. Launch three workers in parallel (one per backend), not one shared shell chain. - In Telegram/direct chat, launch three **background process workers**. - Do not await inline completion. Fire-and-monitor. - Capture the returned process handle / session ID for each worker. - Immediately write/update `/home/ubuntu/.openclaw/workspace/ops/worker-status.md` with: backend, target, handle, state (`queued`/`running`), and the exact intended next step. 3. Run one backend call per folder: - `codex-cli` generates the Codex page - `gemini-cli` generates the Gemini page - `deepseek-code` generates the DeepSeek page - For each backend call, set the worker `workdir` to that backend's target folder. - The command text must start with the backend binary itself (`codex-cli`, `gemini-cli`, or `deepseek-code`). - Do not prepend `cd`, and do not use `&&`, `;`, pipes, or shell builtins in the backend command text. 4. Save each result as a standalone `index.html`. 5. Only after a worker has produced a real `index.html`, start one local server for that folder on its assigned port. 6. Only after that server is running, run one `pipo-deploy` per port/name. - For default previews: `pipo-deploy ` - For agent/site path runs: `pipo-deploy /` 7. If running in background-first mode, return immediately with a launch/status summary and keep monitoring asynchronously. 8. When all workers finish, return the final URLs, or a precise partial-failure report. 9. After every meaningful state change (launch, backend done, html written, server start, deploy done, failure), update `/home/ubuntu/.openclaw/workspace/ops/worker-status.md`. ## Backend Execution Guidance - Prefer minimal one-shot prompts that return raw HTML only. - Keep each backend focused on its own folder and output file. - Do not use `--help` as a fake backend check. - For backend workers, rely on `workdir`; do not embed path changes in the command text. - If the command text begins with `cd`, the worker is malformed and must be corrected before execution. - Do not start `python3 -m http.server` before that backend has already produced a real `index.html`. - Do not substitute the backend generation step with a local server step. Backend generation comes first, then server, then deploy. - For `codex-cli`, if a git repo is required, use a scratch repo only for the backend call itself; do not mix all backends into the same scratch shell chain. - For `gemini-cli`, use the working `gemini-cli` command path already available on this machine. - For `deepseek-code`, use the working `deepseek-code` command path already available on this machine. - Do not replace the three workers with a single helper script unless the human explicitly asks for that shortcut. - Keep one background session per backend and monitor them independently. - For long-running background jobs, prefer completion notifications (`openclaw system event --text ... --mode now`) when the runtime supports them. - For this skill, each worker should emit a completion notification when done, e.g. `openclaw system event --text "Done: codex-demo ready" --mode now`. - After launch, the main agent must be able to answer `status`, `cancel`, and steering requests using the stored process handles. - Do not clear/remove background process sessions until the human explicitly agrees, or until you have already captured the final outcome in the status board. - For `status` requests, prefer reading the stored handle from the status board and then checking the live process. ## Steering and Responsiveness - The human must be able to keep chatting while workers are running. - After delegation, the main agent should remain available for steering, status checks, cancellation, or reprioritization. - If the human asks to change course mid-run, update or stop only the affected worker(s); do not restart the whole orchestration unless necessary. - For status requests, report each worker separately (queued / running / done / failed) and include the known process handles. - For cancellation requests, kill only the targeted background worker by its process handle. - If the human asks “what are they doing?”, report the latest known step from the status board plus the latest available process log snippet. ## Reporting - Background launch acknowledgement: return a concise status line showing the three launched workers, that the chat is free again, and the process handle for each worker. - Success: return the final preview URLs, one per line. - Partial failure: name the failed backend(s), name the successful backend(s), and include only the URLs that are actually up. - No fake confirmations. If no backend call happened, that backend failed.