cocos-scene-prefab-assembly

Cocos Scene Prefab Assembly

Overview

Use this skill when the work is not just writing TypeScript, but making a Cocos Creator scene or prefab playable. The output should identify the node hierarchy, components, serialized properties, asset references, and verification steps needed for the scene to run locally.

Prefer editor/MCP operations when available. If direct editor control is not available, produce an exact assembly plan and avoid claiming the scene is wired until it has been wired.

Assembly Workflow

1. Inspect existing scene and prefab conventions.
   • Look for assets/scenes, assets/prefabs, assets/scripts, assets/ui, assets/resources, and existing manager/root node patterns.
   • If the Cocos local MCP tools are available, use cocos_local_inspect_project first.
   • If direct editor scene access is needed, install or check the Codex editor bridge with cocos_local_install_editor_bridge and cocos_local_check_editor_bridge.
   • Before launching Cocos Creator, reuse an existing editor process for the same project when available. If multiple projects are already open, make the active project and bridge port explicit before applying scene changes.
   • If a new scene asset is needed, use cocos_local_create_scene_from_template to create a Creator 3.8 default 2D scene under assets/scenes.
2. Define the runtime graph.
   • Identify persistent managers, gameplay roots, UI roots, pools, cameras, canvas, and authored content.
   • Define the scene layout contract before node placement: target orientation, design resolution, fit policy, gameplay region, HUD region, safe-area margins, and how narrow/tall screens adapt.
   • For a new 2D mini-game scene, prefer cocos_local_create_minigame_skeleton to generate baseline scripts and a starter scene blueprint before custom assembly.
   • For non-trivial games, use the architecture plan from cocos-creator-gameplay-architecture or cocos_local_create_architecture_skeleton as a guide before placing managers. Scene nodes should host adapters and roots; they do not need to mirror every pure TypeScript system.
3. Map components to nodes.
   • For each component, specify host node, required serialized properties, optional properties, and event bindings.
4. Map assets to references.
   • Identify sprites, audio clips, prefabs, animation clips, fonts, and bundle/resource paths.
   • For from-zero playable scenes, confirm whether each first-loop visual/audio class is generated, existing, deliberately geometry-only, or pending. Do not let missing sprite/UI/SFX/music assets disappear as an implicit scene-assembly choice.
   • For generated gameplay art, confirm role/orientation review and animation requirements before assigning the asset to scene nodes or prefabs.
5. Create or update prefabs for repeated objects.
   • Player, enemy, bullet, pickup, effect, floating text, and reusable UI items should normally be prefabs.
6. Verify scene entry.
   • Confirm start scene, Canvas/camera presence, design resolution alignment, initial state, input path, UI visibility, and reset/restart behavior.
   • If claiming local runtime verification, pair scene assembly checks with cocos_local_collect_runtime_evidence after the project has run in Cocos preview or WeChat DevTools.