メニュー
Daytona cloud server, Den sandbox, desktop plus cloud e2e, marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den. Use for server-side setup in validated flows.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Apply iPolloWork's modern, minimal-change engineering standards when adding features, fixing bugs, refactoring, changing UI, or upgrading dependencies. Use for every implementation task in the iPolloWork repository.
Local iPolloWork Electron browser automation with CDP. Use when driving a local Electron dev app, browser_list, browser_snapshot, browser_eval, composer automation, or local UI smoke tests.
Create an OpenCode plugin for iPolloWork. Scaffolds the plugin file with the correct API shape, tool definitions, and hook registration. Use when the user asks to 'create a plugin', 'write a plugin', or 'make a plugin that does X'.
Daytona development environment overview. Use when the user asks about Daytona setup, Daytona toolbox, dev environment, noVNC, CDP, server sandbox, secrets volume, Electron sandbox, standalone Chrome, validation, or artifacts volume.
Electron and Den, desktop plus cloud, two-sandbox e2e, cloud auth, marketplace, org policy, worker proxy, provider sync, desktop handoff. Validate Electron against a Daytona Den server with unified proof.
do e2e tests, validate feature, prove it works, pass/fail, frame proof, screenshots, CDP assertions. Daytona validation loop for real app behavior with repair before declaring success.
| name | daytona-cloud-server |
| description | Daytona cloud server, Den sandbox, desktop plus cloud e2e, marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den. Use for server-side setup in validated flows. |
Use this skill when the user needs the hosted/server side of iPolloWork running in Daytona. This is separate from the Electron desktop sandbox.
3005.8788.8789.From the repo root:
bash .devcontainer/test-server-on-daytona.sh [branch-or-commit]
The helper creates a separate server sandbox, starts MySQL, Den API, Den Web, and worker proxy, waits for health checks, then prints URLs.
If dependencies or the base image changed, refresh the server snapshot:
bash .devcontainer/create-daytona-ipollowork-server-snapshot.sh
For end-to-end desktop validation, use the daytona-electron-den skill. This
section only covers wiring the Electron sandbox to the printed server URLs.
Start a second Daytona sandbox for Electron and point it at the server URLs:
bash .devcontainer/test-on-daytona.sh [branch-or-commit] \
--den-base-url <DEN_WEB_URL> \
--den-api-base-url <DEN_API_URL>
For flows that must require cloud sign-in, add --require-signin.
Use the public URLs printed by the helper:
curl -sf <DEN_WEB_URL>/api/den/health
curl -sf <DEN_API_URL>/health
Inspect logs if health checks fail:
daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-api.log'
daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-web.log'
daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-worker-proxy.log'
daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-db-push.log'
Use two sandboxes when testing cloud behavior end-to-end: server sandbox for Den and a separate Electron sandbox for the desktop client. This matches production better than trying to run everything inside one desktop sandbox.
Use this for marketplace install/remove/search/filter, org-managed extensions, desktop handoff auth, cloud restrictions, and worker proxy flows.
Pair this with the daytona-recording-artifacts skill. Server proof should
include health-check output, relevant logs, CDP assertions from Electron, and a
recording or screenshot artifact for human review.
Use daytona-flow-validator for pass/fail. Server health alone does not prove
Electron cloud behavior works.