UI Verify

Compare implemented Unity UI against its source mockup. Produces a structured delta report identifying exactly what drifted and what needs fixing.

Skill type: Flexible — checklist adapts to scope, but the read-compare-delta structure is mandatory.

Step 0: Locate the Source Mockup

Before verification, identify the source of truth:

1. If the mockup path was provided by the user or in a task description, use that.
2. Otherwise, check

   docs/mockups/

   for a file matching the feature name (e.g.,

   talent-ui-mockup.html

   for the talent panel).
3. If no mockup exists for this feature, report that verification requires a source mockup and fall back to a theming compliance audit only (Step 3, Theming Compliance and Bug Workarounds categories).

Step 1: Capture Current State

If UI is reachable in current game state:

mcp__UnityMCP__manage_scene(action="screenshot", include_image=true)

Frame the scene view on the target panel first if needed.

If UI is NOT reachable (requires level 25, combat state, NPC interaction, etc.): Skip to Step 2b (code-level audit). Do not ask the user for a screenshot — that happens naturally during playtesting.

Step 2a: Visual Comparison

Re-read the source mockup file. Actually re-read it — do not rely on prior context or memory. The mockup may have been updated, and context drift is the problem this skill exists to solve.

Compare the screenshot against the mockup using the checklist in Step 3.

Step 2b: Code-Level Structural Audit

When screenshots are unavailable, read the implementation source files and compare directly against the mockup CSS/HTML:

USS file audit:

• Open the USS file and the mockup CSS side by side (read both)
• Compare every property value — does each USS selector match its CSS counterpart?
• Are all values using

  var()

  Theme.uss references? Flag any hardcoded values.

C# controller audit:

• Read the controller that builds the VisualElement tree
• Compare element hierarchy against mockup HTML nesting
• Verify element names match mockup class names
• Check for inline style workarounds where the translation map flagged them

Bug workaround audit:

• Any ScrollView children using height/min-height → must be inline C#, not USS
• Runtime UIDocuments → must call

  FontManager.ApplyToRoot(root)

• No

  styleSheets.Add(Resources.Load<StyleSheet>())

  patterns

Step 3: Comparison Checklist

Evaluate each category. Mark each as pass, fail, or warning.

--spacing-*

--font-size-*

skills/shared/uss-effect-decisions.md

Step 4: Delta Report

Produce a structured report using this format:

Confidence tags:

• [PASS-visual]

  — verified via screenshot comparison (high confidence)

• [PASS-code]

  — verified via code-level structural audit only (lower confidence — means "the code looks right" not "the output looks right")

• [FAIL]

  — mismatch found

• [WARN]

  — USS limitation, documented in translation map or uss-approximation-patterns.md

Use

[PASS-visual]

[PASS-code]

## UI Verification: [Component Name]
Source: docs/mockups/[feature]-mockup.html
Method: [screenshot | code-audit]

### Results
[PASS-visual] Layout: hierarchy matches (N containers, correct flex directions)
[FAIL] Spacing: top-bar padding is 8px, mockup uses --spacing-xl (16px)
[FAIL] Color: search-box border hardcoded #2a2a3a, should be var(--color-border)
[PASS-visual] Typography: font sizes match scale
[PASS-code] Borders: widths and radius correct (code-level check only)
[WARN] Interactive: hover states not yet wired (Layer 4 pending)
[FAIL] Theming: 2 hardcoded color values found
[PASS-visual] Bug workarounds: ScrollView height handled via inline C#

### Action Items
1. Fix top-bar padding: change 8px → var(--spacing-xl)
2. Fix search-box border: replace #2a2a3a → var(--color-border)
3. Replace hardcoded colors at [file:line] and [file:line]

Step 5: Fix or Report

If acting as the implementer: Fix each failed item. After fixes, re-run verification (loop back to Step 1). Continue until all items pass or are documented as known limitations.

If acting as a reviewer: Report the delta to the implementing agent or user. Do not fix — the implementer owns the code.

Quality Gate

This skill produces delta reports. When used standalone, invoke

crucible:quality-gate

Scope Adaptation

This skill adapts to verification scope:

• Full panel: Run all checklist categories
• Single component: Focus on that component's categories, skip layout if container structure isn't changing
• Theming audit only: Focus on Theming Compliance and Colors categories
• Post-correction check: Focus on previously-failed categories from the last delta report
• No mockup available: Theming Compliance and Bug Workarounds categories only