メニュー
Help a user integrate a grounded VIVERSE leaderboard into a local world project with one app ID, one leaderboard Studio Meta Name, score submit, and bounded ranking readback.
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-playcanvas-leaderboard |
| description | Help a user integrate a grounded VIVERSE leaderboard into a local world project with one app ID, one leaderboard Studio Meta Name, score submit, and bounded ranking readback. |
| argument-hint | Describe your project folder, your app ID, and your leaderboard Studio Meta Name if you already know it. |
This skill is for a narrow leaderboard 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 backend 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 leaderboard workflow 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 leaderboard 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.
For engine-only local worlds, prefer the existing folder helpers first:
Do not ask the user to name main.js if index.html already exists. The current leaderboard installer and validator can detect the local world script from index.html automatically.
When adding leaderboard support into an already working world, treat the current local behavior as a preservation baseline.
Do not use leaderboard integration as permission to rewrite the world's bootstrap, UI flow, quest flow, interaction flow, or other existing runtime wiring.
Use one small additive integration point instead of a fresh unified architecture.
Keep the current local path working unless the user explicitly asks to replace it.
If leaderboard support introduces a prerequisite such as app identity, sign-in, or leaderboard configuration readiness, gate that path before enabling it.
Do not let a missing leaderboard 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 leaderboard path.
Four-rule hard-stop wording:
Environment-mode rules for this workflow:
Do not use this skill when the user wants:
In those cases, explain that the current leaderboard workflow boundary is narrower than the request.
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.
If the project already has index.html, use the built-in detection in scripts/create-leaderboard-runtime-boundary.mjs and scripts/validate-leaderboard-integration.mjs rather than manually asking the user for the main world script filename.
Preferred plain-language collection shape when details are actually missing:
Project folder: /absolute/path App ID: your app id Leaderboard Meta Name: your Studio Meta Name
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.
If the app ID or leaderboard Meta Name is unknown, stop and ask for it.
When the project target is known but the user does not yet know the app ID or leaderboard Meta Name, 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 other hidden Toolkit-specific sources of truth for the production 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.
Use only this grounded Studio path:
name value for score upload and ranking readback. Treat the Display Name as a separate UI label.~@$-,.. Do not suggest underscores such as gate_speed_run.Do not describe the Studio Meta Name as something the Toolkit can derive locally from project files.
Do not tell the user to look for a field literally called "leaderboard key" in Studio when the UI shows Meta Name instead.
Do not imply that the user can continue without first creating or confirming that leaderboard configuration in Studio.
If the user says they have no leaderboard yet, explain that they must first create the leaderboard configuration in Studio before this workflow can wire score submit or readback against it.
When using this skill, return:
When the request clearly fits this skill, prefer a short reply shape like this before adding implementation detail:
Example opening:
"This is mainly a leaderboard request for one world. The toolkit now has a grounded path for score submit plus bounded ranking readback, and once I have your project folder plus the App ID and Studio Meta Name for that leaderboard, I can wire it in. If app identity is the only blocker and you do not yet have a target world, I can also help create or publish that target first so we can obtain the app ID."
When the user asks where to find the app ID or leaderboard Meta Name, prefer a short answer shape like this before adding more detail:
"You can confirm the App ID in VIVERSE Studio by opening your world and checking the Overview tab. If you do not have a target world yet and app identity is the main blocker, I can also help create or publish that target first through the CLI path so we can obtain the app ID. For the leaderboard setup, open that same world's Upload Content page, go to SDK Settings, and inspect or create the leaderboard there. Studio asks for both Display Name and Meta Name. The Meta Name is the value the code will use as the leaderboard key, and the Display Name stays as the user-facing label. The Meta Name may contain only letters, numbers, and ~@$-,., so do not use underscores. Once you have those values and your project folder, I can wire the leaderboard into your world."
Use an opening shape like this when it fits:
"This is mainly a leaderboard request. The toolkit now has a grounded path for one app ID plus one leaderboard Meta Name, and once I have your project folder plus any missing prerequisite values, I can wire it into your world. If app identity is the only blocker and you do not yet have a target world, I can help create or publish that target first so we can obtain the app ID."
Stop and ask or reroute when any of these are true:
Before treating this path as grounded, validate at least one of these facts:
index.html.If none of those checks can be confirmed, do not present this skill as grounded workflow support.
When the target world already worked before the edit, require at least one preserved-behavior validation step in addition to any new leaderboard validation before claiming completion.
When leaderboard runtime wiring is added, require one environment-mode check before claiming real submit or readback 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.