ui-verify

SKILL.md

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.

Category What to Compare
Layout Flex directions, element order, nesting depth, container structure
Spacing Padding, margins, gaps — compare against mockup's --spacing-* values
Colors Background, text, border — compare against Theme.uss variables used in mockup
Typography Font sizes, weights, letter-spacing — compare against --font-size-* scale
Borders & Radius Border widths, colors, corner radius values
Interactive States Hover, active, disabled, selected — are callbacks wired?
Theming Compliance All values via Theme.uss variables? Any hardcoded colors or sizes?
Bug Workarounds USS bug zones handled correctly? FontManager called?

Step 4: Delta Report

Produce a structured report using this format:

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

### Results
[PASS] 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] Typography: font sizes match scale
[PASS] Borders: widths and radius correct
[WARN] Interactive: hover states not yet wired (Layer 4 pending)
[FAIL] Theming: 2 hardcoded color values found
[PASS] 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.

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
Weekly Installs
1
Repository
raddue/crucible
GitHub Stars
6
First Seen
6 days ago
Installed on
amp1
cline1
opencode1
cursor1
kimi-cli1
codex1