Deft
Ask AI

Search

Search skills, authors and topics

uizze / uizze

anti-ui-slop

Stop coding agents from shipping generic UI. Use UIZZE's 800,000+ real web and iOS screens to build product-specific interfaces, define a design contract, cover required states, and run a hard finish gate. Use when designing, implementing, redesigning, critiquing, or pre-ship reviewing a web or iOS interface in Codex, Claude Code, Cursor, Copilot, or another coding agent. Trigger with "anti-ui-slop", "stop UI slop", "ground this UI in real screens", or "run the UI finish gate".

Install

npx skills add https://github.com/uizze/uizze --skill anti-ui-slop

Uizze craft checks

Adapted from Impeccable's craft floor. Apply after choosing the direction, not as a substitute for one. The project's established system and explicit user choices take priority over general aesthetic preferences.

Inspect the built interface

Check these together while exercising the actual screen:

  • Hierarchy: the primary task or message reads first; supporting information is visibly subordinate. Use scale, weight, alignment and grouping before adding more containers.
  • Typography: readable line lengths and line height; coherent scale; deliberate weights; no clipped ascenders, awkward heading wraps or truncated essential labels. Use tabular numerals for comparisons. A system font is appropriate for native/product UI; choose a distinctive face only when the direction benefits and licensing/loading are handled.
  • Spacing: relationships are visible. Related controls sit together, separate sections have breathing room, and optical alignment agrees with the grid. Avoid arbitrary one-off gaps.
  • Colour: semantic roles stay consistent. Verify text contrast (normally 4.5:1; large text 3:1), focus visibility and readable disabled/error states. Colour alone must not communicate meaning.
  • Surfaces and assets: coherent borders, radii and depth; correct image aspect ratio/crop; sharp assets at displayed size. No broken images, accidental seams or duplicate device/status chrome.
  • Controls: labels describe actions; focus order and keyboard operation work; touch targets are usable. Standard controls remain recognisable. Loading and disabled states explain what is happening, and errors offer recovery.
  • Layout: test the requested width, a narrow/mobile width and the principal desktop/native device class. Long names, empty lists, large text, keyboard insets and overflowing menus must not break the task.
  • Motion: explain continuity, state or feedback. Keep content visible without animation, honour reduced motion, avoid blocking interaction behind entrance sequences, and test interruption/reversal.
  • Content: real product language and credible data. Label fixtures as illustrative. Do not invent customers, testimonials, capabilities or performance results.

Detect habitual design

Repeated icon-title-text cards, decorative charts, nested panels, gradient headlines, glass backgrounds, indiscriminate pill shapes and identical section entrances are common defaults. They are not universal bans. Keep a treatment when it serves the chosen direction or real task; replace it when it adds no information or conflicts with the product.

Ask what the screen actually communicates and enables. “It compiles” and “nothing overlaps” do not establish visual quality. Compare the rendered hierarchy and detail with the user's target, not just with a list of defects.

Close the loop

Batch material corrections, recapture the affected sizes/states, and inspect the new captures. Check actual controls as well as screenshots. Run the project's relevant tests.

Report the scope of verification accurately. Do not turn an unavailable browser, failed service call, skipped device or unresolved finding into a pass. Do not create a novelty score or add effects merely to satisfy a checklist.