auditing-and-refining-ui-art

Designs, polishes, and audits game UX/UI for Godot and Web interfaces.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/alsdmlals4-eng/Base --skill auditing-and-refining-ui-art-alsdmlals4-eng
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: auditing-and-refining-ui-art
Source: https://github.com/alsdmlals4-eng/Base/tree/main/skills/auditing-and-refining-ui-art
Command: npx skills add https://github.com/alsdmlals4-eng/Base --skill auditing-and-refining-ui-art-alsdmlals4-eng

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Game UI work often mixes decoration with structure, lets UI code recompute domain rules, and treats automated checks as proof of player understanding. This Skill separates experience design, information architecture, state ownership, accessibility, polishing, and evidence-based auditing so screens are judged against real renders and declared validation states. ## Core Features & Use Cases - UX/UI Design Modes: Define experience contracts, flow and information architecture, pattern selection (ADOPT/ADAPT/AVOID/TEST/IGNORE), design system tokens, Godot UI contracts, accessibility gates, and playtest contracts. - Polishing Pass: Apply a P0 BLOCKER → P1 CLARITY → P2 CONSISTENCY → P3 DELIGHT priority order with feedback budgets, interruption/reentry fixtures, and before/after evidence. - Runtime UI Audit: Scan Godot and Web sources with a static signal script producing CANDIDATE findings, then confirm against actual renders before any approved minimal fix. - Use Case: Auditing a Godot inventory screen: run the scanner to collect layout, spacing, typography, and color candidates, compare them against the rendered screen at minimum and target resolutions, get user approval, then apply minimal fixes and re-audit in a fresh context. ## Quick Start Ask the AI to audit the UI in your project folder using this Skill and report candidate findings with evidence before making any changes.

Frequently Asked Questions about auditing-and-refining-ui-art

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a Godot UI for layout and readability issues?

Run the included scan_ui_art_signals.py script against your project root to collect static candidates across five areas: decoration, layout, spacing, typography, and color. Each finding is a CANDIDATE, not a confirmed defect, and must be compared against the actual rendered screen before any fix.

How do I polish game UI without breaking existing functionality?

Follow the polishing-pass order: resolve P0 blockers first, then P1 clarity, P2 consistency, and only then P3 delight. Require functional and information-architecture readiness before starting, get approval before edits, and produce before/after evidence under identical conditions.

Does this Skill support Web UI as well as Godot?

Yes. The scanner and audit procedure include a Web adapter covering HTML semantics, CSS flow/flex/grid, focus-visible and state styling, and framework component boundaries, alongside the Godot adapter for Control, Container, Theme, and StyleBox signals.

Can the static scan results be treated as confirmed UI defects?

No. Static results are explicitly marked CANDIDATE and must be verified against the real rendered screen, design intent, accessibility needs, and platform context. Intentional patterns can be recorded with a reasoned allow annotation.

When should I not use this Skill for a UI change?

Skip it for pure domain logic changes like combat, economy, or save systems, for final art asset or prompt production, and for single mechanical fixes that do not alter UX, state, or input contracts. It is also not for HTML planning dashboards.

How does the Skill handle accessibility validation?

It defines an accessibility gate covering information, input, navigation, timing, motion, audio, text, and cognitive barriers with equivalent fallback paths. Automated checks and render captures are never reported as human or screen-reader verification; unrun items stay NOT_RUN or UNVERIFIED.