This role consumes $unity-game-workflow-control 's Work Item and $unity-development-workflow 's scene plan. Visual production uses V0-V4; A0-A6 only indicates action risk, F2 records domain quality, and F3 records Unity project verification.
Inputs and Boundaries
Read the Visual Bible, scene contract, structural sketch, asset registry, performance budget, and current V stage. Only when there is a substantive visual tradeoff, authorization, external generation cost, or alternative strategy, hand the precise question to $unity-game-grilling; do not repeatedly ask about decisions that are already valid.
Production-grade 3D models and PBR textures are handed to $unity-game-3d-modeling and $unity-game-3d-texturingrespectively. When an existing Spine character is only being reskinned and its Bone, Slot, Attachment, Mesh, constraints, and animations are fixed, hand it to $unity-game-spine-reskin。
For specific Unity operations, use plugin specializations: UI is first routed to unity:ui ; Sprite, Atlas, Tilemap, and pixel rendering respectively use unity:sprite-editor、unity:manage-sprite-atlas, the applicable unity:tilemap-* , and unity:2d-pixel-perfect; localization/TMP, URP post-processing, and Shader Graph respectively use the corresponding unity:* Skill. This role only maintains the visual baseline, breakdown, source/assembly decisions, asset identity, and acceptance evidence.
V0-V4
- V0 Triage: Identify the global baseline, scenes, display layers, reference image usage boundaries, and actual delivery types. A scene only contains its own visuals and persistent HUD; modal, popup, drawer, and toast establish independent
DISPLAY_LAYERWork Items. A newly created scene or display layer that contains visible visuals must have a mockup task arranged; when a valid visual specification already exists, use it to guide the mockup, and when direction exploration is needed, generate a number of substantively different candidates determined by the task and let the user choose. - V1 Object Definition: For a newly created
SCENE/DISPLAY_LAYERthat contains visible visuals, submit at least one viewable complete mockup covering the target state and main visual elements, to serve as the target image for V2 breakdown; also submit the sketch/graybox and Scene/Prefab/UXML structure, covering stable node IDs, positional dependencies, semantic grouping, parent-child hierarchy, render order, states, Anchor, Pivot, safe area, masks, asset slots, and Unity-native responsive contracts. Mockups are only used for design and breakdown, and are not registered as formal assets. - V2 Breakdown Confirmation: Establish stable numbering and component x state for visible elements. First determine parent-child relationships by positional dependency; elements that jointly express the same information but have no positional dependency are grouped into the same semantic group and kept at the same level, and it is forbidden to guess parentage by distance, minimum bounding rectangle, or element type. Then separately record
visualRouteAnalysisandassemblyAnalysis: the former determines the source as independent image, reuse, Unity-native drawing, model, material, or VFX, and the latter determines Scene/Prefab/UXML/UIDocument/Canvas/Transform assembly. A single region must not useCOMPOSITEto mix appearance and behavior, nor may a full-screen image be passed off as structured assembly. When user tradeoffs are needed, bind confirmation to a precise version; do not produce or import formal assets before confirmation. - V3 Asset and Composition Acceptance: Independently produce, create, or reuse by number, and verify TextureImporter, SpriteAtlas, fonts, materials, models, VFX, GUID, Addressables, and host same-screen composition in Unity. Assets and
.metabelong to the same ownership unit. - V4 Formal Integration: A single writer assembles Scene, Prefab, or UXML/USS according to the frozen structure, removing grayboxes, placeholder Meshes/Sprites/Materials, temporary objects, and residual references; after compilation/domain reload is stable, submit Game View, EditMode/PlayMode, interaction, layout, Console, and performance evidence.
Production rules
- Reference images and high-fidelity images are only used for content, composition, and information hierarchy; it is forbidden to crop, cut out, enlarge, or lightly retouch them and use them as Sprites/textures, and it is also forbidden to lay out the entire image as a base to pass off as a structured implementation.
- If a generative transparent bitmap first produces an opaque single solid-color background PNG, use
scripts/remove-background-local.mjsto perform solid-color background removal from the canvas edges; explicitly record the background color, tolerance, source/output SHA, deleted pixels, and light/dark background previews; onlyPASSoutput can enter Unity import. This script must not be used for reference image cutouts, and is also not suitable for complex backgrounds, hair, glass, glow, or semi-transparent edges. - For static featured appearance, prioritize delivering independent images, models, materials, or VFX; procedural routes are only used for content with qualifying evidence, such as text, dynamic data, layout, basic geometry, progress, particles/Shader, etc.
REUSEmust bind the source path/SHA, Unity GUID, license, Importer, consuming nodes, and most recent verification evidence; 'looks similar' cannot replace identity. - UI/2D bitmaps by default plan the source pixel density at
sourceScale=1of the target maximum display size, unless pixel art or an approved platform budget explicitly overrides it. It is not browser DPR; runtime scaling must read the actual configuration of CanvasScaler, PanelSettings, Camera, Screen, dynamic resolution, and Importer. SpriteAtlas, compression, MipMap, Read/Write, color space, and Addressables are still determined by the Unity platform budget. - Procedural text must cover
en、zh-CN、ja、ru、es, per language declaresingle-lineorwrap, and verify TMP/UI Toolkit font fallback, actual glyph width, baseline, and container; truncation is forbidden. - Independent DISPLAY_LAYERs verify open, interaction, close, and focus/input/underlying state restoration in the host context; their failure or delay is not written back as the host scene being incomplete.
- During the development phase, only perform Editor/Game View/PlayMode visual verification. Without explicit user request, do not launch Standalone/Player or real devices.
Deliver the current asset ID, GUID/address, path, specifications, import conventions, and limitations to gameplay; deliver item-by-item checks, cleanup, Editor screenshots, and budget evidence to QA; deliver source, license, and generation records to release. When complex transparent edges lack an independent mask or clean background, they must be redrawn or regenerated; do not fake transparent results.