Update to Unity

{
  "description": "Unity uGUI (Canvas-based) UI expert. Understands, edits, and generates Canvas hierarchies, RectTransforms, Layout Groups, and prefab UI. Use for requests involving Canvas, uGUI, RectTransform, or .prefab UI files.",
  "included_files": [
    {
      "relative_path": "references/scrollview-setup.md",
      "size_in_bytes": 1576
    }
  ],
  "name": "ui-ugui",
  "skill_md_contents": "---\nname: ui-ugui\ndescription: Unity uGUI (Canvas-based) UI expert. Understands, edits, and generates Canvas hierarchies, RectTransforms, Layout Groups, and prefab UI. Use for requests involving Canvas, uGUI, RectTransform, or .prefab UI files.\n---\n\nUnderstand existing Unity uGUI, make targeted edits, and generate new Canvas-based hierarchies.\n\nWhen working with ScrollRect/ScrollView, read the reference file:\n- `references/scrollview-setup.md` — Required hierarchy, setup rules, and common failures\n\n## Scope\n\nDetermine what the user is asking for:\n\n| Request Type | Action |\n|--------------|--------|\n| Question about UI | **Understand** — analyze hierarchy, explain structure |\n| Change specific element | **Edit** — targeted modification only |\n| Create new UI | **Generate** — create new hierarchy |\n| Fix/improve existing UI | **Edit** — modify existing, don't rebuild |\n\n**Generate only what is requested:**\n\n| Request | Output |\n|---------|--------|\n| UI layout | Prefab or scene hierarchy only |\n| \"with code\" / \"with logic\" / \"functional\" | Hierarchy + scripts |\n\n**These do NOT imply scripts:**\n- \"proper buttons\" → well-configured Button components\n- \"working UI\" → valid hierarchy that renders\n- \"menu screen\" → visual layout only\n\n## Critical Rules\n\n**Namespace disambiguation:**\n- Always use fully qualified type names when creating or referencing UI components\n- `UnityEngine.UI.Image`, not `Image`\n- `UnityEngine.UI.Button`, not `Button`\n- Other namespaces in the project can cause ambiguous type errors\n\n**Verify before modifying:**\n- Always check what currently exists before making changes\n- Confirm parent objects exist before adding children\n- Verify components are present before modifying properties\n- Never assume hierarchy state — query it first\n\n**Incremental fixes over rebuilds:**\n- When fixing issues, make targeted corrections\n- Never destroy and recreate entire hierarchies to fix problems — destroyed objects cause null reference cascades\n- Prefer identifying the specific broken property and fixing only that over rewriting large sections\n- **When a fix fails, revert the change** before trying an alternative approach\n\n**One change at a time:**\n- Make a single change, then verify the result\n- Do not batch multiple unrelated modifications\n- Be careful not to inadvertently modify or remove adjacent elements when editing a specific one\n- If something fails, understand why before trying alternatives\n- Avoid \"shotgun debugging\" with multiple simultaneous changes\n\n**Color and visibility:**\n- **Ensure text is readable by default:** When choosing colors, ensure text contrasts with its background — but respect intentional low-contrast uses (disabled states, placeholder text, decorative elements)\n- **Check visibility for new elements:** After creating UI elements, verify they have non-zero size and are within parent bounds. Elements intentionally created hidden (for later toggling, animation, etc.) are fine\n\n**Specification adherence:**\n- **Honor user specifications exactly:** When the user provides pixel dimensions, hex colors, positions, spacing, or other exact values, apply them precisely — do not approximate or substitute\n- **Minimize unrelated changes:** When editing, avoid changing properties the user didn't ask about unless a related adjustment is necessary for the fix to work\n\n## Conventions\n\n**Follow project patterns first.** Search existing files before applying defaults.\n\n| Type | Convention | Good | Bad |\n|------|------------|------|-----|\n| GameObject names | PascalCase | `SubmitButton` | `submit-button` |\n| Prefab paths | Feature folders | `Assets/UI/Inventory/` | `Assets/Prefabs/UI/` |\n\n## Workflow\n\n1. **Verify state** — Check what exists in the scene/hierarchy before any action.\n2. **Analyze** — Determine exactly what's needed. No extras.\n3. **Search** — Find existing prefabs, canvases, assets. Don't assume paths.\n4. **Follow project patterns** — Match folder structure and naming.\n5. **Create or edit** — Build structure with proper anchoring, or make targeted edits.\n6. **Confirm result** — Verify the change worked before moving on.\n\n## Canvas Setup\n\nEvery UI needs a Canvas:\n\n```\nCanvas (Screen Space - Overlay or Camera)\n├── CanvasScaler (Scale With Screen Size recommended)\n├── GraphicRaycaster\n└── [UI Content]\n```\n\n**CanvasScaler settings:**\n- Default to UI Scale Mode \"Scale With Screen Size\" unless the project has a specific reason for \"Constant Pixel Size\" (e.g., pixel-art, fixed-resolution targets)\n- Reference Resolution: Match project standards (e.g., 1920x1080)\n- When creating a Canvas with Screen Space - Camera, **read the camera's reference resolution** first\n- Match Width Or Height: 0.5 (balanced)\n- If an existing Canvas uses \"Constant Pixel Size\", flag it and ask the user before changing\n- Prefer anchors and Layout Groups over absolute pixel positions for layout\n\n## Layout Components\n\n**Layout Groups control child sizing:**\n- When a parent has a Layout Group, it manages child RectTransforms\n- Children's anchors and sizeDelta may be overridden by the parent\n- Understand whether the parent or child controls size before setting values\n\n**Vertical/Horizontal Layout Groups:**\n- Control Child Size: determines if parent sets child dimensions\n- Child Force Expand: determines if children stretch to fill space\n- If Control Child Size is off, children must have explicit sizes\n\n**Avoiding layout conflicts:**\n- Do not manually set child anchors/size when parent controls them\n- Do not add Layout Group to an element that should have fixed size\n- Nested Layout Groups require careful configuration of each level\n- When layout is wrong, check parent settings before modifying child\n- ContentSizeFitter on the **same** object as a Layout Group that has Control Child Size enabled = conflict\n- ContentSizeFitter on a child whose parent has Control Child Size enabled = ContentSizeFitter is overridden (wasted)\n- When using ContentSizeFitter with a Layout Group parent, disable Control Child Size on the parent for the relevant axis\n- Common pattern: ScrollView Content should have ContentSizeFitter + VerticalLayoutGroup where VLG controls children but ContentSizeFitter sizes the Content itself\n\n**Grid Layout Group:**\n- For inventory grids, card layouts\n- Cell Size must be set explicitly — children are sized to match\n- Constraint controls row/column limits\n\n**Content Size Fitter:**\n- Horizontal/Vertical Fit: Preferred Size\n- Use on containers that should size to their content\n- Requires a layout element or text component to provide preferred size\n\n## RectTransform Anchoring\n\n**Elements must have non-zero size to be visible:**\n- Set explicit width/height via sizeDelta, or\n- Use stretch anchors with proper offsets, or\n- Let a parent Layout Group control size (with Control Child Size enabled)\n\n**Anchor configuration order:**\n1. Set anchor preset first (corner, edge, or stretch)\n2. Then set position/offset values\n3. Verify the resulting size is non-zero\n\n**Common patterns:**\n- **Stretch anchors** — for responsive elements that fill available space\n- **Corner anchors** — for fixed-position, fixed-size elements\n- **Edge anchors** — for elements that stretch in one direction only\n\n**Positioning from natural language descriptions:**\nWhen the user describes a position (e.g., \"top right\", \"bottom bar\", \"left side\"):\n1. Determine if it's a **corner** (fixed point), an **edge** (stretch along one axis), or **fill** (stretch both axes)\n2. Set anchor min and anchor max — for corners these are the same point; for edges/fill they span a range\n3. **Set pivot to match the anchor point** — pivot must align with where the element is anchored, not left at the default (0.5, 0.5). A \"top right\" element needs pivot at the top-right corner; a \"top bar\" needs pivot at the top edge center\n4. Set position/offset values **after** anchors and pivot are configured\n\n**Visibility checklist:**\n- Width and height are both greater than zero\n- Element is within parent bounds\n- Element is not obscured by siblings (check hierarchy order)\n- Image component has a sprite or color with alpha > 0\n\n## Common Components\n\n| Component | Use Case |\n|-----------|----------|\n| `Image` | Backgrounds, icons |\n| `RawImage` | Render textures, videos |\n| `Text (TMP)` | All text (use TextMeshPro) |\n| `Button` | Clickable elements |\n| `Toggle` | Checkboxes, radio buttons |\n| `Slider` | Value ranges |\n| `ScrollRect` | Scrollable content |\n| `InputField (TMP)` | Text input |\n\n## Best Practices\n\n- Use TextMeshPro for all text (not legacy Text)\n- WorldSpace UI that have text should also use Text Mesh Pro, be sure to review the project and import the TMP essentials if they are not present in the project\n- If the TextMeshPro Essentials were imported be sure to close the TMP Importer Windows and the Import Unity Package Window once the assets are imported\n- Organize hierarchy logically (Header, Content, Footer)\n- Use Layout Groups instead of manual positioning where possible\n- Set Raycast Target = false on non-interactive images\n- Use sprite atlases for performance\n\n**Never use** `EditorApplication.ExecuteMenuItem(\"Window/TextMeshPro/Import TMP Essential Resources\")`, unless the user asks for an interactive TMP Essentials installation. It opens a modal dialog that blocks whatever invoked it until a human dismisses it.\n\n**Do not use** `AssetDatabase.ImportPackage()` for TMP resources, instead `TMP_PackageResourceImporter.ImportResources()` is the canonical non-interactive API.\n\n## Interaction Readiness\n\nBefore completing any UI that contains interactive elements, verify:\n\n1. **EventSystem** must exist in the scene (exactly one)\n2. **GraphicRaycaster** must be on the Canvas\n3. **Raycast Target = true** on interactive elements (and false on non-interactive ones to avoid blocking)\n4. **Button.onClick should be wired** (via inspector or script) — only when scripts or logic were requested\n\nIf the first three are missing, interactive elements will exist visually but fail silently.\n\n## Understanding\n\nWhen the user asks questions about existing UI:\n\n**Read the hierarchy first.** Don't assume — always inspect the scene or prefab before answering.\n\n**Analyze structure:**\n- Identify the Canvas and its render mode\n- Map the parent-child relationships\n- Identify which Layout Groups control which children\n- Check RectTransform anchor configurations\n\n**Answer questions about:**\n- \"What does this button do?\" → Explain component, hierarchy position, event wiring\n- \"How is this laid out?\" → Describe Layout Groups, anchoring, hierarchy\n- \"Why is this invisible?\" → Check size, anchors, parent bounds, component state\n- \"What controls this element's size?\" → Trace Layout Group settings or anchors\n\n## Editing\n\nFor targeted changes to existing UI:\n\n**Read before editing.** Always inspect the current state first.\n\n**Edit workflow:**\n1. Verify the target object exists\n2. Identify the specific property or component to change\n3. Make the minimal change required\n4. Verify the result before proceeding\n\n**Never destroy to fix:**\n- Destroying objects cascades to null references elsewhere\n- Fix properties in place rather than recreating\n- If an element must be removed, update all references first\n\n## C# (Only When Requested)\n\n- Use fully qualified UI types to avoid namespace conflicts\n- Use `[SerializeField]` for inspector references\n- Cache component references in Awake()\n- Use events/delegates for button callbacks\n- Place scripts in same folder as prefabs (follow project patterns)\n\n**Component references:**\n- Verify referenced objects exist before accessing them\n- Handle cases where serialized references may be null\n- When wiring up references, confirm the target component is present\n\n## Error Recovery\n\nWhen something goes wrong:\n\n**Stop and diagnose:**\n- Identify the exact error or symptom\n- Determine the root cause before attempting fixes\n- Do not make speculative changes\n\n**Fix incrementally:**\n- Address one issue at a time\n- Verify each fix before moving to the next\n- Keep track of what was changed\n\n**Avoid destructive patterns:**\n- \"Start fresh\" strategies destroy working elements along with broken ones\n- Rebuilding entire hierarchies creates more problems than it solves\n- Prefer surgical fixes to wholesale replacements\n\n**When stuck:**\n- Re-verify the current state of the hierarchy\n- Check if previous changes were actually applied\n- Consider if the approach itself is wrong rather than the implementation\n"
}