메뉴
Help a user integrate low-risk default-room multiplayer into a local VIVERSE world project without implying generic multiplayer support. Not for matchmaking, named rooms, or host-authoritative gameplay; use viverse-multiplayer for those.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Three.js Polygon Streaming .xrg integration and debugging playbook for @polygon-streaming/web-player-threejs, including correct wrapper events, asset publishing, model fitting, and fallback replacement policy
Bundle entry for the exported VIVERSE PlayCanvas Toolkit workflow pack. Use when you want bundled VIVERSE PlayCanvas Toolkit skills, prompts, catalogs, and helper assets in one standalone package.
Collision detection patterns for Three.js games without physics engines
Protect third-party API keys by moving secret-bearing calls into VIVERSE Play Lambda scripts and keeping only non-secret user data in VIVERSE Storage.
Build or fix CPU racing drivers for Three.js or VIVERSE racing games. Use for waypoint loops, tile-to-route reconstruction, lap completion, recovery logic, and low-overhead debug workflows.
VIVERSE Login SDK integration for user authentication and SSO
| name | viverse-default-room-multiplayer |
| description | Help a user integrate low-risk default-room multiplayer into a local VIVERSE world project without implying generic multiplayer support. Not for matchmaking, named rooms, or host-authoritative gameplay; use viverse-multiplayer for those. |
| argument-hint | Describe your local project folder and whether you only need default-room shared presence or synchronized interactions. |
This skill is for a narrow multiplayer request in a user-owned local project.
Use it only when the user wants one of these outcomes:
Treat the user as the end user of the workflow by default.
Do not reinterpret a direct invocation as a request to maintain skills, prompts, or repo memory unless the user explicitly asks for customization maintenance.
This skill is not for generic multiplayer design.
Do not treat this skill as proof that the repo already supports:
If the user's request depends on any of those, stop and say that the request goes beyond the current default-room multiplayer scope.
This skill is grounded in these repo-local sources:
Do not promise behavior beyond what those sources can support.
Treat those grounded sources and the current Toolkit skill workspace as an explicit allowed exception to target-folder-only implementation search. You may consult or execute this workspace's skills/, prompts/, docs/, scripts/, packages/, catalog, contract, checklist, and review files when they are the grounded helper surface for the requested multiplayer workflow. This exception does not authorize inspecting other sibling user project folders outside this workspace.
Use this skill when all of these are true:
scripts/index.mjs for PlayCanvas Editor-exported projects, and main.js (or whatever single JS entry the index.html loads) for engine-only local worlds scaffolded by viverse-engine-only-local-world.If the target project is missing, ask for the local project folder before discussing implementation details.
When the project is an engine-only local world (no PlayCanvas Editor export, no scripts/index.mjs), the NetworkSystem from packages/network must be registered against the pc.Application before app.start() runs. Translate any Editor-script-based wiring described in the network package guide into code-only equivalents: create an entity, add a script component, and instantiate the relevant script class in JS. Do not ask the user to do this step; do it for them in the same edit that wires multiplayer in.
When adding default-room multiplayer into an already working world, treat the current local behavior as a preservation baseline.
Do not use multiplayer as permission to rewrite the world's bootstrap, player lifecycle, interaction flow, quest flow, or UI wiring.
Use one small additive integration point instead of a fresh unified architecture.
Keep the current single-player or offline path working unless the user explicitly asks to replace it.
If multiplayer introduces a new prerequisite such as app identity, auth state, or service readiness, gate that path before enabling it.
Do not let a missing multiplayer prerequisite break an existing local path that already worked.
Before claiming completion, name at least one existing behavior that must still work after the edit and verify that preserved behavior in addition to the new multiplayer path.
Four-rule hard-stop wording:
Runtime proof rules for this workflow:
Do not use this skill when the user wants:
In those cases, explain that the current default-room workflow boundary is too narrow and that broader multiplayer support is not yet formalized.
Before giving executable guidance, collect all of these and infer them only when the target project's own files identify them safely:
For engine-only local worlds, detect the entry file by reading the <script> tags in index.html instead of asking the user to name the file.
For Editor-exported projects, use the conventional scripts/index.mjs path unless the target project's own files show a different bootstrap.
Preferred plain-language collection shape when details are actually missing:
Project folder: /absolute/path Multiplayer goal: default-room shared presence / default-room synchronized interactions
If the project folder is unknown, stop and ask for it.
If the main world script cannot be inferred safely, stop and ask for it.
When the project target is known but the user does not yet know the app ID, give bounded prerequisite guidance instead of stopping with a vague request.
Use only these grounded paths:
viverse-cli app list to see existing application IDs.Do not invent Toolkit-specific local-file sources of truth for the production app ID.
Do not imply that default-room multiplayer can be turned on before the app ID is known.
If the user does not yet have a world in Studio, explain that they must first create or confirm the target world there, then return with the App ID.
If the app ID is the only remaining blocker and the user does not yet have a target world or app, ask one short practical question about whether they want to create or publish that target now in order to obtain the app ID.
If they do want to create or publish it now, reroute to viverse-cli-publish as the preferred path so the agent can create the target app and obtain the app ID directly; use direct Studio creation only when the CLI publish path is unavailable or the user explicitly wants the Studio path.
Do not turn missing app ID into an open-ended workflow discussion. Only offer the publish or create-world path when app identity is the actual blocker.
When using this skill, return:
Use an opening shape like this when it fits:
"This is mainly a default-room multiplayer request. The toolkit already has networking capability for that narrower path, and once I have your project folder plus the exact multiplayer goal and any missing app-identity prerequisite, I can ground the integration."
Stop and ask or reroute when any of these are true:
Before treating this path as grounded, validate at least one of these facts:
When implementation begins, validate the runtime path with these additional checks when they apply:
If none of those checks can be confirmed, do not present this skill as grounded workflow support.
If the request clearly fits this skill and required inputs are missing, the immediate next action should be one short question asking for:
Ask for the runtime bootstrap file only if it cannot be inferred from the project structure.