菜单
Translate a user scene or feature request into a plan that reuses existing Toolkit support, chooses the right output path, and answers in plain language for non-technical users by default.
用 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 | compose-toolkit-capabilities |
| description | Translate a user scene or feature request into a plan that reuses existing Toolkit support, chooses the right output path, and answers in plain language for non-technical users by default. |
| argument-hint | Describe what you want to make or what help you need, plus any must-have details you already know such as your project folder or target world. |
Use this skill when the user describes a scene, feature, or gameplay idea in natural language and the main job is to map that request onto existing toolkit capabilities.
The goal is not to invent a fresh implementation first.
The goal is to:
Always start from what the player should do and what the world should do in response.
Decompose the request into:
Then match Toolkit support to those slices.
Do not start by searching for a prior scene name, old prototype name, or one-file example that looks superficially similar.
When the user is asking for a feature in their own world, treat the destination as the user's local project folder.
For in-world scene behavior:
scripts/index.mjs for PlayCanvas Editor-exported projects, or index.html plus the single JS entry it loads for engine-only local worldspackage.json plus index.html plus a local JS entry, treat that as the source of truth and modify it in placeskills/, prompts/, docs/, scripts/, packages/, catalog, contract, checklist, and review docs may be consulted or executed when they are the grounded helper surface for the requested workflowWhen the local project folder is missing, ask one short practical question in the user's language.
Preferred question shape:
Preferred wording example:
Use toolkit-capability-catalog.md as the human-readable catalog of reusable capabilities and output routes.
Use toolkit-capability-catalog.json as the primary machine-readable routing catalog.
Use toolkit-api-discovery-index.json as the API-level lookup table for concrete Toolkit systems, triggers, actions, and interaction primitives.
When an indexed API entry includes config field hints, construction hints, or capability hints, use those hints before inventing custom filters, helper state, wrapper config names, or replacement control surfaces.
Use internal catalog names, file paths, and field names silently. In user-facing replies, prefer plain language and do not mention internal scaffold names, source file paths, runtimeReadiness, integrationRecommendation, or scripts/index.mjs unless the user explicitly asks for implementation details.
Do not anchor on the currently open editor file or the most recently discussed internal example unless the user explicitly asks about it.
For interaction-heavy requests, consult the catalog's interaction cue map before inventing low-level control logic.
When a request can plausibly map to an existing Toolkit API, consult the API discovery index before writing bespoke scene logic.
When the proposed solution depends on a specific Toolkit config field, method argument, or property name, verify the exact name from the package type or source declaration before claiming it exists or falling back to bespoke code.
When the user asks to add a new capability into an already working world, treat the current working behavior as a preservation baseline, not as disposable scaffolding.
Do not rewrite the existing app bootstrap, player setup, quest flow, interaction flow, or UI wiring just because a new feature touches those surfaces.
Use the smallest additive integration point that can host the new capability.
If a request such as multiplayer, networking, quest expansion, or interaction ownership appears to touch multiple systems, do not respond by restructuring the whole world first.
Instead:
Compact review and execution rules:
Match the user's behavior language against the API index intent cues first, especially for:
If the user request sounds like a zone trigger, player-only activation, or another authored world reaction, first check Toolkit trigger or action primitives and inspect their config shape before inventing an update loop, a position poller, a distance check, or a custom filter helper. Prefer an existing trigger or action config field when one exists.
Choose one route first.
Choose this when the feature should land in the user's own world code.
Use it for:
Choose this when the feature is better expressed as a stable generated template.
Use it for:
Choose this when the user's real need is a workflow step rather than a scene feature.
Use it for:
Within workflow help, disambiguate before answering:
Preferred handoff once the route is clear:
Follow this order:
Before saying that a Toolkit capability is unavailable or before falling back to bespoke scene code, verify the nearest real availability evidence you have:
toolkit-source-manifest.jsontoolkit-api-discovery-index.json when the request is about a concrete runtime behaviorDo not widen implementation search into neighboring user folders just because the target folder is empty, incomplete, or missing a needed feature. If the target folder is empty, scaffold there. If it is incomplete, repair or extend that folder. If a needed asset path is outside the target folder, use only the specific user-provided asset path rather than searching nearby folders for alternatives.
When extending an existing working world, extend the current entrypoint and runtime wiring in place instead of replacing them with a fresh unified flow.
For multiplayer or networking additions in an existing world:
Do not claim that quest, extension, ui, or other Toolkit capability slices are unavailable based only on an older scaffold shape or an older cached assumption.
Do not jump straight to writing custom code when the repo already contains a reusable route.
Consult the structured catalog first when choosing between capabilities with similar surface descriptions.
Use the catalog to match behavior slices, not to hunt for a past scene name.
When implementation is requested, write into the user's local project main world script rather than this Toolkit repo, unless the user explicitly requested Toolkit maintenance.
If implementation is requested but the local project folder is missing, the immediate next action should usually be asking for that folder path.
If the project folder is known, resolve the technical landing point yourself and ask the user only for missing product or business details that cannot be inferred safely.
If the task includes local preview, derive the preview route from the target project itself before starting a server:
package.json scripts or equivalent local preview entry firstIf the request includes avatar movement, traversal, colliders, rigid bodies, or physics-heavy interaction, add a short implementation preflight before proposing file edits:
If the implementation changes interaction behavior, physics, trigger routing, selection, quest progression, or UI state, do not treat a successful build as sufficient proof that the fix works.
Before claiming the feature is fixed, require at least one behavior-facing validation step such as:
When the target world already worked before the edit, require at least one preserved-behavior check in addition to any new-feature check.
Examples of preserved-behavior checks include confirming that an existing quest panel still renders, an existing trigger still fires, an existing collider still blocks movement, or an existing click interaction still selects the intended target.
If the request includes publishing or deployment:
Do not treat preview-only examples as production-ready runtime surfaces unless the task explicitly includes promoting them.
Do not reintroduce preview validation flows as the final product path when a runtime scripts/index.mjs route already exists.
Before proposing implementation, classify the request into one or more of these buckets:
Then choose the route and the capabilities.
For interaction-heavy requests, explain the intended interaction flow first in plain language, then map that flow onto Toolkit support.
When a leaderboard or ranking request clearly stays within one app ID, one leaderboard Studio Meta Name, score submit, and bounded top-entries or self-rank readback, prefer handing off to viverse-playcanvas-leaderboard instead of treating it as open-ended backend design.
If that leaderboard request is otherwise in scope but the user does not yet know the app ID or leaderboard Studio Meta Name, keep the route pointed at viverse-playcanvas-leaderboard and let that workflow give the bounded prerequisite recovery steps; when app identity is the only blocker and no target world exists yet, let that workflow ask whether the user wants to create or publish the target world now through the preferred CLI publish path.
When a multiplayer or networking request clearly stays within default-room shared presence or default-room synchronized interactions, prefer handing off to viverse-default-room-multiplayer instead of treating it as open-ended multiplayer architecture.
If that multiplayer request is otherwise in scope but the app ID is still missing, keep the route pointed at viverse-default-room-multiplayer and let that workflow either give the bounded app-ID recovery steps or, when app identity is the only blocker and no target world exists yet, ask whether the user wants to create or publish the target world now through the preferred CLI publish path.
When the structured catalog already contains a matching capability, prefer its recorded outputRoute, runtimeReadiness, and integrationRecommendation over ad hoc reinterpretation.
When canModifySource is false, treat the source file as read-only unless the task explicitly allows modifying it.
If a capability is internal or experimental, keep that name out of the user-facing answer by default and describe the capability in plain language instead.
When using this skill, return:
For non-technical users, prefer wording such as:
Avoid leading with wording such as:
When the request clearly matches one of these route types, prefer a short answer shape like these before adding implementation detail.
Good outcomes look like this:
Avoid outcomes like this:
reference-only capability with thin-integration-layer as if the source file itself were already the final runtime surface