uw-ui-toolkit-binder

UI Toolkit Binder

Generate MVVM UI code using Unity 6's Runtime Data Binding.

Before You Start

1. Read docs/ProjectConfig.yaml for:
   • ui_system — must be "UIToolkit" or "Mixed". If "UGUI", this skill does not apply.
   • architecture_pattern — "so-first" or "di-first" (affects how ViewModels get their data).
   • mcp.unity_mcp — if true, call refresh_unity after creating files.
2. Read docs/NAMING_CONVENTIONS.md — UXML files use PascalCase (e.g., PlayerHUD.uxml), USS files match (e.g., PlayerHUD.uss).
3. Read docs/CODING_STANDARDS.md — class structure order, serialization rules, async patterns apply to ViewModels.
4. If UI motion/animation is needed, check docs/GFD_Template.md for guidelines and use uw-game-feel-integrator for tween integration.

When to Use UI Toolkit vs uGUI

Use Case	Recommended	Why
Menus, settings, inventories, data-heavy UI	UI Toolkit	Batched rendering, no GameObject overhead, CSS-like styling
Animated in-game HUD, world-space UI	uGUI	Easier world-space Canvas, mature animation workflow
Complex project with both	Hybrid	UI Toolkit for menus, uGUI for in-game HUD

If ProjectConfig.yaml -> ui_system is "UGUI", stop here — use uGUI patterns instead.

Architecture

Model (Data/SO) --> ViewModel ([CreateProperty] MonoBehaviour) --> View (UXML + USS)

• Model: Game data — ScriptableObjects, runtime state, network state. The ViewModel reads from these.
• ViewModel: A MonoBehaviour with [CreateProperty] on properties. This is the binding source. It bridges game data to UI elements without the View knowing about game logic.
• View: UXML defines layout, USS defines styling. Bound to ViewModel properties via DataBinding in a controller script.

File Structure

For a feature called PlayerHUD inside a feature module:

Features/PlayerHUD/
├── Scripts/
│   ├── {RootNamespace}.PlayerHUD.asmdef
│   ├── PlayerHUDViewModel.cs
│   └── PlayerHUDController.cs
├── UI/
│   ├── PlayerHUD.uxml
│   └── PlayerHUD.uss
└── Tests/
    └── {RootNamespace}.PlayerHUD.Tests.asmdef