You are responsible for a comprehensive **game UI and HUD professionalization pass**.

Your job is to make the existing game's interface feel:

- intentional;
- cohesive;
- readable;
- polished;
- visually consistent;
- professionally designed;
- appropriate to the game's existing visual identity;
- free of prototype-looking or programmer-looking presentation;
- consistent across menus, windows, HUD elements, tooltips, prompts, and interaction states.

The primary question throughout this task is:

> **What currently makes this interface look or feel like unfinished development UI instead of a professionally shipped game's interface?**

Then fix those problems.

This is an **implementation task**, not merely a UI audit.

Do not stop after:

- listing inconsistent panels;
- identifying spacing problems;
- creating a style guide;
- recommending typography changes;
- describing better menu hierarchy;
- generating a polish backlog.

Inspect the actual interface, identify concrete weaknesses, prioritize them, implement worthwhile improvements, validate them across representative resolutions and gameplay states, reassess with fresh eyes, and continue while meaningful UI improvement remains.

The goal is:

> **Make the existing UI/HUD feel like one coherent interface system designed intentionally for this specific game.**

---

# UI Professionalism Is the Priority

Prioritize approximately:

1. visual hierarchy;
2. consistency;
3. typography;
4. spacing and alignment;
5. panel and component styling;
6. HUD composition;
7. state clarity;
8. icon consistency;
9. layout stability;
10. information density;
11. responsive presentation;
12. tooltips and contextual information;
13. interaction presentation;
14. subtle transition polish;
15. last-mile consistency.

This ordering is not rigid.

Fix the highest-value interface weaknesses actually present.

---

# Core Scope

This pass owns the **interface itself**.

Relevant areas may include:

- HUD;
- menus;
- inventory;
- equipment;
- character panels;
- skill panels;
- ability bars;
- action bars;
- combat HUD;
- health and resource displays;
- XP displays;
- quest interfaces;
- dialogue UI;
- crafting UI;
- gathering interfaces;
- maps;
- minimaps;
- chat UI;
- social UI;
- party UI;
- notifications;
- alerts;
- tooltips;
- context menus;
- modals;
- confirmation dialogs;
- settings screens;
- title screens;
- pause menus;
- loading screens where interface-driven;
- progress bars;
- buttons;
- tabs;
- lists;
- cards;
- rows;
- tables;
- grids;
- scrollbars;
- sliders;
- dropdowns;
- text inputs;
- selection states;
- hover states;
- pressed states;
- disabled states;
- focus states where relevant;
- iconography;
- typography;
- borders;
- backgrounds;
- separators;
- badges;
- counters;
- status indicators;
- resource indicators;
- target frames;
- enemy/player frames;
- objective trackers;
- notification stacks;
- error and success messages;
- empty states;
- loading states;
- pending states;
- confirmation states.

Only improve UI systems that actually exist.

---

# Explicitly Out of Scope

This is **not primarily**:

- an environment-art pass;
- lighting polish;
- material polish;
- world composition;
- a game-feel overhaul;
- input-system redesign;
- accessibility expansion;
- backend architecture cleanup;
- networking work;
- persistence work;
- economy redesign;
- progression redesign;
- balance redesign;
- content creation;
- animation-system reconstruction;
- broad audio production;
- broad performance optimization.

Some interaction behavior may be changed when necessary to make an existing UI element coherent, complete, or functionally presentable.

Do not allow this task to become a general UX, accessibility, backend, gameplay, or architecture pass.

Record worthwhile out-of-scope findings separately.

---

# Preserve the Existing Visual Identity

Do not replace the game's interface with your preferred design language.

First determine the existing UI identity.

Inspect:

- existing panels;
- fonts;
- colors;
- icons;
- borders;
- corner treatment;
- textures;
- shadows;
- highlights;
- button styles;
- tab styles;
- headers;
- separators;
- HUD composition;
- strongest existing screens;
- the game's broader art direction.

Identify:

> **What does this game's interface appear to be trying to look like?**

Then make it a stronger version of itself.

Do not casually turn:

- fantasy UI into modern SaaS UI;
- minimal UI into ornamental parchment UI;
- dark UI into bright UI;
- stylized UI into flat web UI;
- pixel UI into vector UI;
- diegetic UI into generic floating panels.

Professionalization should increase **cohesion**, not erase identity.

---

# UI Is Not a Website

Do not automatically apply generic web-dashboard conventions to a game.

Avoid turning the interface into:

- a SaaS dashboard;
- an admin panel;
- a mobile banking app;
- a Bootstrap-style website;
- a generic card grid;
- an endless stack of rounded rectangles;
- a design-system demo.

A game UI should reflect:

- gameplay;
- world identity;
- pacing;
- input method;
- visual hierarchy;
- information urgency.

Use game-specific presentation where appropriate.

---

# Professional Does Not Mean Ornamental

Do not assume professionalism requires:

- gradients everywhere;
- animated borders;
- glow on every button;
- heavy textures;
- elaborate frames;
- oversized drop shadows;
- constant transitions;
- decorative flourishes;
- gold trim;
- particles behind menus.

A professional interface may be simple.

What matters is that it appears:

- deliberate;
- consistent;
- readable;
- balanced;
- polished.

Use decoration only when it supports the game's identity.

---

# Inspect Before Asking Questions

Use the actual project as evidence before asking for clarification.

Inspect relevant:

- interface scenes or prefabs;
- component definitions;
- stylesheets;
- themes;
- reusable widgets;
- HUD configuration;
- assets;
- fonts;
- icons;
- screenshots;
- runtime views;
- resolution/layout rules;
- localization behavior;
- existing conventions;
- documentation;
- platform targets;
- supported input modes.

Ask for clarification only when:

- the game's intended visual identity cannot be established;
- multiple materially different design directions are equally plausible;
- a change would alter important gameplay or UX behavior;
- platform or localization requirements cannot be determined;
- required assets or access are unavailable;
- proceeding would create significant redesign risk.

Do not ask questions merely because inspecting the existing interface takes effort.

---

# Implementation Over Auditing

The audit exists only to create an **implementation queue**.

Do not spend most of the task:

- documenting every widget;
- writing style-guide prose;
- listing every spacing difference;
- producing huge critique documents;
- describing subjective UI theory.

Once enough evidence exists to improve a coherent interface area:

> **implement it.**

Use this loop:

> **Inspect → identify inconsistency or weakness → implement → validate → compare → continue**

Work through related component families so improvements remain systematic.

---

# Inspect the Actual Interface

Where practical, inspect the UI running.

Use:

- screenshots;
- runtime views;
- scenes or prefabs;
- UI layouts;
- stylesheets or themes;
- component definitions;
- icons;
- fonts;
- HUD configuration;
- responsive rules;
- animation states.

Code alone may not reveal:

- visual imbalance;
- cramped spacing;
- hierarchy problems;
- clipped text;
- poor alignment;
- excessive density;
- inconsistent styling.

Use actual rendered output whenever possible.

If direct runtime inspection is unavailable, state that limitation and use the best available evidence rather than pretending visual validation occurred.

---

# Establish Representative Screens

Identify the major interface contexts players regularly see.

Depending on the game, these may include:

- normal gameplay HUD;
- inventory;
- equipment;
- character stats;
- skills;
- quest log;
- crafting;
- dialogue;
- bank or storage;
- map;
- settings;
- pause menu;
- combat state;
- loot or reward screens;
- title or main menu;
- multiplayer or social UI;
- alternate layouts for supported platforms.

Use representative screens as the baseline for comparison.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports multiple parallel workers, agents, subprocesses, or independent contexts, use them only where they materially improve throughput or review quality.

Do not require delegation.

A single capable session should be able to complete this prompt sequentially.

When parallel work is available:

- parallelize independent screen families;
- centralize typography, color, spacing, base controls, and shared visual rules;
- avoid having multiple workstreams modify the same shared UI foundation simultaneously;
- review all shared changes for cross-screen consistency.

Good independent areas may include:

- HUD;
- inventory;
- crafting;
- dialogue;
- quests;
- social UI;
- settings;
- icon consistency;
- typography review.

Serialize work involving shared:

- typography;
- global theme;
- base buttons;
- panel primitives;
- color tokens;
- icon pipeline;
- modal infrastructure;
- shared grid/list components;
- common HUD foundations.

Define shared rules first.

Then apply them consistently.

---

# UI Priority Queue

Classify findings approximately as follows.

## P0 — Broken UI

Examples:

- text unreadable;
- severe overlap;
- clipped essential information;
- inaccessible controls;
- panels off-screen;
- invisible controls;
- incorrect layering;
- modal traps;
- broken responsive layout;
- missing icons;
- important state visually incorrect.

Fix these immediately.

---

## P1 — Major Professionalism Problems

Examples:

- obvious engine-default controls;
- wildly inconsistent screens;
- programmer-looking layouts;
- poor information hierarchy;
- major spacing inconsistency;
- mismatched fonts;
- mismatched icons;
- arbitrary colors;
- HUD clutter;
- major alignment problems;
- key screens appearing unfinished;
- inconsistent panel treatment;
- inconsistent button language.

These strongly affect perceived quality.

---

## P2 — Significant Polish

Examples:

- weak typography hierarchy;
- inconsistent padding;
- inconsistent border thickness;
- icon scale variation;
- mediocre tooltip styling;
- weak empty states;
- imperfect status presentation;
- inconsistent progress bars;
- inconsistent list rows;
- weak responsive behavior;
- noisy dense layouts.

Spend substantial effort here.

---

## P3 — Finishing Details

Examples:

- small spacing differences;
- minor baseline misalignment;
- subtle border inconsistencies;
- minor icon offsets;
- modest transition polish;
- tiny hierarchy improvements;
- small capitalization inconsistencies.

These details matter after larger issues are solved.

---

# Establish the UI Design Language

Before broad implementation, identify the game's effective UI language.

Determine:

- primary font;
- secondary font where justified;
- major text sizes;
- text hierarchy;
- primary panel treatment;
- secondary panel treatment;
- border language;
- corner treatment;
- separator style;
- highlight style;
- selected-state style;
- disabled-state style;
- icon style;
- button language;
- color hierarchy;
- warning/success/error conventions;
- tooltip treatment.

Use the strongest existing screens as evidence.

Do not automatically redesign the entire system.

Where possible, standardize upward toward the best existing implementation rather than toward the average.

---

# Typography Pass

Typography is one of the most visible indicators of interface quality.

Inspect:

- font family;
- size;
- weight;
- line height;
- letter spacing where relevant;
- capitalization;
- truncation;
- wrapping;
- alignment;
- contrast.

Establish clear hierarchy for:

- major screen title;
- section heading;
- normal label;
- secondary label;
- body text;
- metadata;
- tooltip text;
- numeric values;
- warnings.

Look for:

- too many font sizes;
- arbitrary bolding;
- tiny unreadable metadata;
- oversized headings;
- inconsistent capitalization;
- labels competing with values;
- random alignment.

Typography should communicate importance, not merely decorate.

---

# Spacing Pass

Inspect:

- outer margins;
- panel padding;
- section gaps;
- row height;
- button padding;
- icon/text gap;
- label/value spacing;
- grid spacing;
- tooltip padding.

Look for:

- inconsistent spacing;
- cramped controls;
- excessive empty space;
- arbitrary one-off values;
- alignment drift;
- panels with different internal rhythm.

Where practical, consolidate common spacing values into shared definitions.

Do not force every measurement onto an artificial mathematical scale if the existing visual style clearly calls for exceptions.

---

# Alignment Pass

Check:

- text baselines;
- icon centering;
- panel edges;
- headers;
- list columns;
- progress values;
- buttons;
- labels;
- resource counts;
- HUD groups.

Small alignment errors strongly communicate:

> **prototype**

Fix visible misalignment systematically.

---

# Visual Hierarchy Pass

Every screen should communicate:

> **What should I notice first?**

Inspect whether:

- the title dominates appropriately;
- the primary action is obvious;
- secondary actions remain secondary;
- critical values stand out;
- decorative elements do not compete;
- metadata does not dominate;
- status information has appropriate emphasis.

Avoid giving every element equal visual weight.

Use:

- scale;
- weight;
- contrast;
- spacing;
- positioning;
- grouping.

---

# Panel and Container Pass

Inspect major panels.

Look for inconsistency in:

- backgrounds;
- opacity;
- borders;
- corner treatment;
- framing;
- padding;
- shadows;
- header treatment;
- dividers.

Equivalent panels should usually share a visual language.

Do not create a different frame style for every feature without a clear reason.

Avoid excessive nested boxes.

Use spacing and hierarchy instead of borders for every grouping opportunity.

---

# Button Pass

Inspect button families.

Check:

- height;
- padding;
- typography;
- icon placement;
- borders;
- background;
- normal state;
- hover state where applicable;
- pressed state;
- selected state;
- disabled state;
- destructive state;
- primary versus secondary hierarchy.

Equivalent buttons should behave and look equivalent.

Do not use ten slightly different button styles.

Do not make every action visually primary.

---

# Tab Pass

Inspect:

- active tab;
- inactive tab;
- hover;
- disabled state;
- spacing;
- indicator;
- typography;
- content alignment.

Tabs should make the current context immediately obvious.

Avoid active states that differ only through extremely subtle color changes.

---

# Icon Pass

Inspect related icons for consistency in:

- perspective;
- detail level;
- scale;
- padding;
- stroke;
- fill;
- outline;
- lighting direction;
- background treatment;
- framing.

Look for:

- oversized icons;
- tiny icons;
- inconsistent visual weight;
- raster/vector mismatch;
- unrelated icon packs;
- placeholder symbols;
- text glyphs or Unicode being used where proper icons already exist.

Normalize presentation.

Do not redesign every icon unless inconsistency genuinely warrants it.

---

# HUD Composition Pass

The HUD should communicate important gameplay state without unnecessarily obscuring the game.

Inspect relevant:

- health;
- mana or equivalent resource;
- XP;
- action bars;
- minimap;
- target frame;
- quest or objective tracker;
- notifications;
- status effects;
- chat;
- interaction prompts.

Ask:

- What information is always needed?
- What information is situational?
- What information is redundant?
- What visually competes with the game world?
- What is difficult to scan?

Improve:

- grouping;
- hierarchy;
- spacing;
- anchoring;
- visual weight.

Do not remove useful information merely to achieve minimalism.

Do not let every system permanently demand HUD space.

---

# Information Density Pass

Inspect dense interfaces such as:

- inventory;
- bank or storage;
- crafting;
- skills;
- statistics;
- trade;
- social lists.

Look for:

- too much text;
- weak grouping;
- wasted space;
- excessive padding;
- crowded controls;
- repetitive labels;
- noisy separators.

Optimize density for actual usage.

Dense interfaces can still look professional.

The solution is not automatically to make everything larger.

---

# Inventory and Equipment Pass

If present, inspect:

- slot sizing;
- grid spacing;
- icon padding;
- item quantity presentation;
- rarity or status treatment;
- selected item;
- hovered item;
- equipped item;
- empty slots;
- disabled slots;
- tooltip relationship;
- equipment silhouette or layout.

Look for:

- inconsistent item framing;
- awkward quantities;
- overly decorative slots;
- icon clipping;
- noisy backgrounds;
- weak selection states.

---

# Skill and Progression UI Pass

If present, inspect:

- skill icons;
- levels;
- XP;
- progress bars;
- current and next progression;
- selected skill;
- category grouping.

Ensure numeric information is easy to scan.

Avoid unnecessarily repeating equivalent information.

Do not redesign progression itself.

---

# Progress Bar Pass

Normalize where appropriate:

- height;
- border;
- fill;
- background;
- labels;
- percentage or value placement;
- animation.

Different systems may use distinct colors, but progress bars should still feel like members of the same interface family.

---

# Tooltip Pass

Tooltips should feel intentional.

Inspect:

- padding;
- maximum width;
- typography;
- title/body hierarchy;
- icon use;
- stat formatting;
- line spacing;
- positioning;
- clipping;
- consistency.

Avoid:

- giant tooltips;
- walls of text;
- wildly inconsistent layouts;
- poor contrast;
- tooltips extending off-screen;
- unnecessary duplication of already visible information.

Tooltips should answer the immediate contextual question efficiently.

---

# Modal and Confirmation Pass

Inspect:

- title;
- message;
- primary action;
- secondary action;
- destructive action;
- spacing;
- backdrop;
- size;
- hierarchy.

Do not make every interaction modal.

When modals exist, make them consistent.

Dangerous actions should be distinguishable without making the entire screen look like an emergency.

---

# Notification Pass

Inspect relevant:

- achievement notifications;
- XP gains;
- quest updates;
- loot notices;
- errors;
- warnings;
- system messages.

Look for:

- overlapping notifications;
- too many simultaneous styles;
- excessive persistence;
- weak hierarchy;
- inconsistent positioning;
- messages hidden behind other UI.

Normalize presentation where appropriate.

---

# Error, Warning, Success, and Pending States

Establish consistent treatment for:

- error;
- warning;
- success;
- pending;
- informational state.

Do not use arbitrary one-off colors across different screens.

Use appropriate combinations of:

- icon;
- text;
- color;
- placement.

Avoid excessive alarming presentation for routine conditions.

---

# Empty States

Inspect screens with no content.

Examples:

- empty inventory category;
- no quests;
- no friends;
- no search results;
- no crafting matches;
- empty storage.

Avoid interfaces that appear broken when empty.

Use concise, intentional empty-state presentation.

Do not turn every empty state into tutorial prose.

---

# Loading and Pending Presentation

Where UI depends on asynchronous operations, inspect:

- loading state;
- disabled state;
- pending action;
- delayed data;
- refreshing data.

The goal here is **visual completion**, not backend redesign.

Avoid:

- sudden blank panels;
- layout collapse;
- invisible pending state;
- controls appearing active while already processing.

Keep presentation consistent.

---

# Scrollbar Pass

Inspect scrollbars where present.

Check:

- width;
- visibility;
- contrast;
- track;
- thumb;
- relationship to panel styling.

Default engine or browser-style scrollbars can strongly undermine an otherwise custom interface.

Do not overdecorate them.

---

# Context Menu Pass

Inspect:

- padding;
- row height;
- separators;
- hover or selected state;
- icon alignment;
- disabled actions;
- submenu behavior where present.

Context menus should feel like part of the same interface system.

---

# Lists and Rows

Normalize list presentation.

Inspect:

- row height;
- alternating backgrounds if used;
- separators;
- selected rows;
- status icons;
- trailing actions;
- alignment;
- text truncation;
- empty rows.

Avoid every list independently inventing its own row component.

---

# Tables and Data Grids

Where present, inspect:

- column hierarchy;
- header styling;
- numeric alignment;
- row density;
- sorting indicators;
- selected state;
- clipping;
- horizontal overflow.

Game interfaces should not accidentally resemble spreadsheet software unless that presentation is intentional.

---

# Text and Terminology Consistency

Search for accidental inconsistencies such as:

- "HP" versus "Health";
- "XP" versus "Experience";
- capitalization differences;
- punctuation differences;
- inconsistent abbreviations;
- pluralization differences;
- title-case inconsistencies.

Do not rewrite established game terminology merely for stylistic preference.

Standardize obvious accidental inconsistency.

---

# Numeric Presentation

Inspect how numbers appear.

Examples:

- health;
- currency;
- XP;
- damage;
- inventory quantity;
- percentages;
- timers.

Look for:

- inconsistent separators;
- excessive decimals;
- inconsistent abbreviations;
- unclear units;
- varying alignment.

Equivalent values should use equivalent formatting.

---

# Layout Stability

UI should not visibly jump around unnecessarily.

Look for:

- buttons moving when labels change;
- panel widths constantly changing;
- notifications shifting unrelated content;
- value updates changing alignment;
- tooltips resizing excessively;
- icons shifting when text wraps;
- counters changing width unpredictably.

Stability contributes strongly to professional presentation.

---

# Resolution and Scaling Pass

Test representative supported resolutions and aspect ratios where practical.

Inspect:

- narrow layouts;
- wide layouts;
- high-resolution displays;
- UI scale options where supported;
- unusual supported aspect ratios.

Look for:

- clipping;
- huge unused areas;
- panels becoming excessively wide;
- unreadably tiny UI;
- overlapping HUD;
- stretched components.

Do not invent support for platforms the game does not target.

Test the actual supported environment.

---

# Responsive Reflow

Where the project already adapts layouts, prefer deliberate reflow rather than arbitrary shrinking.

Examples:

- side-by-side panels becoming stacked;
- toolbars wrapping;
- secondary information collapsing appropriately;
- grids changing column count.

Do not let responsive behavior destroy hierarchy.

---

# UI State Completeness

Reusable controls should correctly handle the states that actually occur.

Potential states include:

- normal;
- hovered;
- pressed;
- selected;
- disabled;
- active;
- pending;
- empty;
- unavailable.

Do not create unused states merely for theoretical completeness.

But avoid controls that visibly break when a real state occurs.

---

# Interaction-State Visual Consistency

Equivalent interactive elements should communicate state using a coherent visual language.

For example:

- selected inventory item;
- selected skill;
- selected tab;
- selected target;

do not need to look identical, but they should feel related.

Avoid one system using:

- glow;

another:

- thick border;

another:

- scale animation;

and another:

- no visible state;

without a clear reason.

---

# Animation and Transition Restraint

This is not a dedicated animation pass.

Use subtle transitions where they materially improve perceived quality.

Possible areas:

- modal appearance;
- panel changes;
- tab transitions;
- notifications;
- tooltip appearance;
- progress updates.

Avoid:

- long fades;
- bouncing panels;
- constant scaling;
- excessive easing;
- animations that slow repeated UI use.

UI should feel polished, not theatrical.

---

# Default-UI Hunt

Actively search for untouched defaults.

Examples:

- engine-default buttons;
- default checkboxes;
- default sliders;
- default dropdowns;
- default scrollbars;
- default fonts;
- default focus visuals;
- placeholder panels;
- plain text where established styled controls already exist.

Defaults are not inherently bad.

But isolated stock widgets inside an otherwise custom game often communicate:

> **unfinished**

Normalize them where worthwhile.

---

# Programmer-UI Hunt

Search for interfaces that appear designed only to expose internal data.

Signs include:

- raw values;
- debug terminology;
- labels everywhere;
- giant text dumps;
- controls arranged in implementation order;
- arbitrary vertical lists;
- every section boxed;
- no hierarchy;
- raw internal IDs;
- exposed enum names;
- variable-like labels.

Translate existing functionality into intentional player-facing presentation.

Do not hide information players genuinely need.

---

# Placeholder Hunt

Search for:

- placeholder icons;
- placeholder text;
- temporary colors;
- temporary panels;
- debug labels;
- raw asset names;
- mock values;
- unfinished tabs;
- obvious TODO UI.

Only replace placeholders when the underlying functionality clearly exists.

Do not turn future planned features into current implementation work.

---

# Screenshot Test

Where practical, capture representative screens.

Ask:

> **If this screenshot appeared on the game's store page or promotional material, what immediately makes the UI look unfinished?**

Look for:

- weak hierarchy;
- random spacing;
- mismatched fonts;
- inconsistent icon scale;
- default controls;
- cramped layouts;
- excessive boxes;
- awkward empty space;
- poor alignment;
- clipped text;
- noisy HUD.

Fix high-value findings.

---

# "One Team Designed This" Test

Compare major screens side by side.

Ask:

> **Do these interfaces look like they were designed by the same team for the same game?**

Compare relevant:

- inventory;
- equipment;
- skills;
- dialogue;
- crafting;
- settings;
- HUD;
- quests;
- social UI;
- menus.

Look for:

- unrelated border styles;
- random typography;
- different spacing philosophies;
- unrelated icon framing;
- arbitrary color systems;
- inconsistent buttons.

Standardize accidental inconsistency.

---

# "What Still Looks Unfinished?" Review

Perform a fresh final review focused on what still communicates:

> **unfinished development UI**

rather than:

> **professionally finished game interface**

Look for:

- programmer UI;
- raw defaults;
- inconsistent panels;
- poor typography;
- weak visual hierarchy;
- misalignment;
- mismatched icons;
- awkward spacing;
- excessive boxes;
- visual clutter;
- inconsistent controls;
- unfinished states;
- temporary-looking screens.

Require concrete evidence.

For each meaningful finding establish:

### Screen or Component

Where is the issue?

### Problem

What looks unfinished or unprofessional?

### Evidence

What visible characteristic supports that conclusion?

### Recommended Fix

What specific improvement is justified?

### Scope

Tiny / Small / Medium / Large.

Implement worthwhile fixes.

Reject vague taste.

---

# Work in UI Waves

Do not make random tweaks across the whole interface.

Work systematically.

## Wave A — Global UI Language

Establish or refine:

- typography;
- shared colors;
- spacing;
- panels;
- buttons;
- tabs;
- common states;
- icon treatment.

Validate representative screens.

## Wave B — Core HUD

Polish relevant:

- health and resources;
- targets;
- action areas;
- quest/objective tracking;
- notifications;
- gameplay prompts.

Validate during gameplay.

## Wave C — Major Screens

Polish high-frequency interfaces such as:

- inventory;
- equipment;
- skills;
- crafting;
- quests;
- dialogue;
- maps;
- social systems;
- settings.

Prioritize actual project usage.

## Wave D — Secondary Components

Polish:

- tooltips;
- modals;
- scrollbars;
- lists;
- context menus;
- progress bars;
- status indicators;
- empty states;
- loading states.

## Wave E — Last 10%

Search for:

- tiny alignment errors;
- icon inconsistencies;
- padding differences;
- capitalization issues;
- clipped text;
- inconsistent disabled states;
- odd separators;
- weak transitions;
- leftover defaults.

This accumulation often distinguishes:

> **pretty good**

from:

> **finished**

---

# Reassess After Every Wave

Ask:

- Which screen currently looks weakest?
- Which component still looks default?
- Which interface family remains inconsistent?
- Where is hierarchy unclear?
- Where is typography weak?
- Which HUD element is too visually dominant?
- Which area wastes space?
- Which area is too dense?
- Where are icons mismatched?
- Which screen still looks like programmer UI?
- Did shared changes expose other inconsistencies?

Update priorities.

Do not mechanically follow an outdated initial plan.

---

# Productive Session Loop

Do not stop after the first major normalization.

UI professionalization often exposes the next weakest layer.

Examples:

- better typography reveals spacing problems;
- better spacing reveals icon inconsistency;
- improved panels make older buttons look weak;
- better buttons expose poor tab styling;
- improved major screens make secondary modals look unfinished.

Continue:

> **inspect → identify weakest interface layer → implement → validate → reinspect**

while meaningful UI improvement remains.

Do not invent cosmetic churn merely to continue making changes.

Stop when remaining findings are primarily:

- subjective;
- tiny;
- outside scope;
- require major new assets;
- require product redesign;
- provide negligible perceived improvement.

---

# Regression Review

After shared UI changes, check representative screens for:

- clipping;
- overlap;
- unreadable text;
- missing states;
- broken layout;
- incorrect controls;
- disabled controls appearing active;
- lost information;
- unexpected scaling;
- hidden actions;
- interaction regressions.

A prettier screen that becomes harder to use is not a successful polish.

---

# Performance Awareness

This is not primarily a performance pass.

Avoid UI polish that introduces:

- excessive real-time layout rebuilding;
- unnecessary texture memory growth;
- excessive animation;
- constantly recreated components;
- expensive blur effects;
- excessive transparency;
- particle-backed interface effects without justification.

Prefer strong visual gains at reasonable cost.

---

# Independent Final Review

Where possible, use fresh context or an independent review pass near completion.

Evaluate separately:

## Typography and Hierarchy

Inspect:

- text hierarchy;
- readability;
- consistency;
- information emphasis.

## Layout and Spacing

Inspect:

- alignment;
- padding;
- margins;
- density;
- whitespace.

## Components and States

Inspect:

- buttons;
- tabs;
- panels;
- lists;
- modals;
- selection;
- disabled states;
- pending states.

## HUD

Inspect:

- hierarchy;
- clutter;
- positioning;
- gameplay readability.

## Iconography

Inspect:

- scale;
- perspective;
- style;
- framing;
- visual weight.

The purpose of independent review is to find remaining inconsistencies, not to approve the work.

---

# Anti-Redesign Review

Before completion, inspect whether the pass drifted too far.

Ask:

- Did we change the game's identity?
- Did we create generic web UI?
- Did we overuse cards?
- Did everything become rounded rectangles?
- Did we add unnecessary decoration?
- Did we remove useful information?
- Did we make dense screens inefficient?
- Did we prioritize aesthetics over gameplay readability?
- Did we create unnecessary shared abstractions?
- Did we make routine actions slower?

Undo unjustified changes.

The goal is:

> **professionalization, not replacement**

---

# Final Cross-System UI Review

Before finishing, inspect for:

- inconsistent typography;
- inconsistent panels;
- mismatched button styles;
- mismatched icon sizes;
- inconsistent state styling;
- broken scaling;
- clipping;
- layout shifts;
- unreadable states;
- leftover default widgets;
- programmer-facing labels;
- temporary placeholders;
- partial visual migrations.

Fix worthwhile findings.

Then run final validation.

---

# Completion Standard

The UI/HUD polish pass is complete when, to the degree the existing project allows:

1. major screens feel visually intentional;
2. the UI feels consistent with the game's visual identity;
3. typography has clear hierarchy;
4. spacing is substantially more consistent;
5. alignment errors are reduced;
6. primary and secondary actions are visually distinguishable;
7. equivalent controls share a coherent visual language;
8. panels and containers feel related;
9. icon sizing and framing are more consistent;
10. HUD hierarchy is clearer;
11. HUD clutter is reduced where justified;
12. dense information remains efficient to scan;
13. tooltips feel intentional and consistent;
14. progress indicators are coherent;
15. notifications are visually consistent;
16. loading, empty, and pending states look complete;
17. obvious default-engine-looking controls are reduced;
18. programmer-looking UI is reduced;
19. major screens no longer look like unrelated systems;
20. representative supported resolutions remain usable;
21. important controls and information remain accessible;
22. no known UI regressions introduced by the pass remain;
23. ordinary screenshots no longer expose obvious unfinished UI;
24. remaining weaknesses are low-value, subjective, require major new assets, or belong to another specialized pass.

The objective is not:

> **maximum decoration**

The objective is:

> **maximum improvement in hierarchy, cohesion, clarity, consistency, visual identity, and perceived interface quality using the UI that already exists.**

---

# Final Report

When complete, provide a concise UI-production report.

## 1. Overall Result

Summarize the most meaningful interface improvements.

## 2. Global UI Language

Describe meaningful changes to:

- typography;
- spacing;
- panels;
- controls;
- colors;
- icons.

## 3. HUD

Summarize meaningful HUD changes.

## 4. Major Screens

Describe substantive improvements by actual screen or system.

## 5. Components and States

Summarize meaningful work involving:

- buttons;
- tabs;
- tooltips;
- modals;
- progress bars;
- notifications;
- selection states;
- disabled states;
- pending states.

## 6. Responsive and Resolution Validation

State which supported resolutions, aspect ratios, or layout conditions were checked.

## 7. Consistency Improvements

Describe major inconsistencies that were corrected.

## 8. Validation

State exactly what was validated, including relevant:

- builds;
- runtime screens;
- resolutions;
- interaction states;
- clipping checks;
- layout checks.

## 9. Deliberately Unchanged

Describe notable issues preserved because:

- they are intentional;
- evidence was insufficient;
- new assets are required;
- redesign risk was too high;
- they belong to another pass.

## 10. Remaining Opportunities

List only genuinely worthwhile future UI work.

For each include:

- **Opportunity**
- **Player-facing benefit**
- **Scope:** Tiny / Small / Medium / Large
- **Relevant screen/system**
- **Recommended priority**

Do not pad the report with microscopic styling preferences.

---

# Final Directive

**Think like a game UI director, not a generic frontend developer.**

The interface should look like it belongs to this game.

Prioritize:

> **visual hierarchy, cohesion, consistency, readability, and professional presentation**

over novelty.

Do not redesign the game.

Do not drift into broad accessibility work.

Do not drift into backend architecture.

Do not turn the UI into a website.

Do not add decoration merely because empty space exists.

Do not create a different style for every feature.

Repeatedly ask:

> **Does this look like intentionally designed game UI or development UI?**

> **Does this screen visually belong to the same product as the other screens?**

> **Can the player immediately tell what matters most?**

> **What still looks temporary, default, inconsistent, cramped, noisy, or amateur?**

Continue:

> **inspect → diagnose → implement → validate → compare → reinspect**

while meaningful interface improvement remains.

Leave behind the **same game's UI**, but make it feel substantially more cohesive, deliberate, readable, polished, and professionally shipped.