git:20260722.e39595b to v1.2.13

35 added, 86 removed. Audit A to A.

---

name: anti-ui-slop

- description: 'Stop Codex, GitHub Copilot, Claude Code, and Cursor from shipping generic UI. Use UIZZE’s public catalogue of 800,000+ real web and iOS screens to extract product-specific design decisions and enforce a hard finish gate for web and iOS interfaces.'

+ description: '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".'

+ license: MIT

+ metadata:

+ version: "1.2.13"

+ author: "UIZZE <business@uizze.com>"

+ compatibility: "Designed for Claude Code, Codex, Cursor, and GitHub Copilot; works in any agent that can read project files and fetch a URL."

+ tags: "ui-design, design-system, design-review, frontend, web-ui, ios-ui"

---

- # Anti UI Slop

- Use this skill when building, refactoring, or reviewing a web or iOS interface. The goal is not to make a generic layout prettier. The goal is to make the interface visibly belong to this product, support its real user job, and behave correctly in every important state.

- Browse 800,000+ real web and iOS screens at https://uizze.com before choosing a layout.

- The workflow is instruction-only. It does not execute third-party code or require credentials.

- ## 1. Inspect the Product Before Designing

- Read the repository and identify:

- - the primary user and the job this screen must complete;

- - the single primary action and the information needed before taking it;

- - the existing component library, design tokens, typography, and layout conventions;

- - real product nouns, workflows, constraints, and data already present in the codebase;

- - required loading, empty, error, partial, success, disabled, and permission states;

- - relevant mobile, tablet, desktop, keyboard, and assistive-technology behavior.

- Do not invent product requirements, analytics, user research, or hidden states.

- ## 2. Collect Real Interface Evidence

- Search the public catalogue at https://uizze.com and select three to five relevant web or iOS screens. Prefer references that match the target workflow, information density, navigation model, or interaction pattern—not merely its industry or color palette.

- For each reference, record:

- 1. the screen or flow and its source link;

- 2. the structural decision worth transferring;

- 3. why that decision fits this product;

- 4. what must not be copied.

- Transfer hierarchy, workflow shape, density, navigation, control behavior, responsive treatment, and state handling. Never copy another product’s branding, proprietary text, imagery, or exact layout.

- If catalogue browsing is unavailable, ask the user for two or three UIZZE links or screenshots. If they cannot provide them, continue from repository evidence and label the missing reference evidence explicitly.

- ## 3. Write a Design Contract

+ > **Stop AI coding agents from shipping generic UI.**

- Before changing code, write a short contract with these fields:

+ # Stop Making UI Slop

- | Field | Decision |

- | --- | --- |

- | Screen job | The one outcome this screen enables |

- | Primary user and action | Who acts, and what they do |

- | Content hierarchy | What must be understood first, second, and third |

- | Navigation and controls | Product-specific structure and interaction model |

- | Visual language | Type, spacing, density, surfaces, imagery, and motion rules |

- | Required states | Loading, empty, error, partial, success, disabled, permission |

- | Responsive behavior | What changes across supported widths and input modes |

- | Evidence used | Reference links and transferable decisions |

- | Forbidden defaults | Generic patterns that would erase product specificity |

- | Acceptance criteria | Observable conditions required before shipping |

+ Build product-specific UI with 800,000+ real web and iOS screens via [UIZZE](https://uizze.com).

- The contract must name concrete choices. “Clean,” “modern,” “intuitive,” and “premium” are not design decisions.

+ ![Stop Making UI Slop with UIZZE](https://uizze.com/landing/anti-ui-slop-skill-banner.png)

- ## 4. Build in the Product’s Language

+ ## Overview

- - Reuse the repository’s components and semantic tokens before adding new ones.

- - Make the primary action visually and structurally obvious.

- - Use product-specific labels and information rather than placeholder metrics or generic copy.

- - Keep repeated cards only when the content is genuinely a repeated collection.

- - Add decoration, motion, badges, or elevation only when they communicate state or hierarchy.

- - Implement every required interaction and state; do not leave convincing-looking inert controls.

- - Preserve accessibility semantics, focus order, contrast, touch targets, and reduced-motion behavior.

+ Use the product brief, existing UI, components, and local design system to make intentional interfaces. Uizze supplies focused design guidance and, when useful, a small number of relevant visual references.

- ## 5. Run the Finish Gate

+ ## Prerequisites

- Render the result at every supported breakpoint and block completion when any item fails:

+ - A screen or component to build, redesign, or review — a file path or a short description.

+ - The product's existing components, design tokens, and visual language, so the build extends them instead of inventing a new system.

+ - Optional access to the paid Uizze MCP for focused references and hosted materials.

- ### Product specificity

+ ## Authentication

- - Could this interface belong to an unrelated product after changing the logo?

- - Does the hierarchy reflect the real user job and product data?

- - Are there interchangeable dashboard cards, filler metrics, vague headings, or generic calls to action?

+ - The free skill and public catalogue work without an account, token, MCP connection, dependency, script, or executable.

+ - The optional full UIZZE MCP may use the host's normal connection and authentication flow. Never claim it is connected without an actual host result.

- ### Interaction completeness

+ ## Work from the product

- - Do all visible controls have a real outcome?

- - Are loading, empty, error, success, disabled, and permission states implemented where applicable?

- - Are destructive, irreversible, or sensitive actions confirmed appropriately?

+ Read the brief, existing UI, components, tokens, and constraints before designing. They always outrank this skill. Keep familiar interaction conventions and make the product's own objects, workflow, and priorities visually clear. Do not add novelty for its own sake.

- ### Responsive and accessible behavior

+ ## Load one playbook

- - Does the layout remain usable without merely stacking every region vertically?

- - Do keyboard navigation, focus visibility, semantics, contrast, and touch targets pass inspection?

- - Does content remain readable at zoom and with longer real-world text?

+ Choose at most one file for the current request:

- ### Design-system integrity

+ - New interface or major redesign: `reference/new-work.md`

+ - Product or dashboard work: `reference/operate.md`

+ - Refinement and polish: `reference/polish.md`

+ - Simplification or distillation: `reference/distill.md`

+ - Explicit audit: `reference/audit.md`

+ - Native iOS work: `reference/ios.md`

- - Are local tokens and components used consistently?

- - Is every new visual rule justified by the design contract?

- - Is borrowed evidence transformed into this product’s own visual language?

+ Do not load a second playbook. Apply judgment rather than treating its examples as a checklist.

- Fix every blocking failure and re-run the gate before declaring the UI complete.

+ ## Optional Uizze evidence

- ## 6. Handoff Format

+ Read `references/uizze-reference-policy.md` before using the paid MCP. It exposes exactly `find_ui_references` and `find_ui_materials`. Use them only when a concrete unresolved visual or material question would benefit from evidence. If they return nothing, continue silently.

- Report the finished work in this order:

+ ## Finish

- 1. **Evidence:** the references and decisions that influenced the result.

- 2. **Contract:** the final product-specific design rules.

- 3. **Implementation:** the meaningful interface and behavior changes.

- 4. **Verification:** breakpoints, interaction states, and accessibility checks performed.

- 5. **Remaining risks:** anything that could not be verified, without overstating completion.

+ Complete the requested scope. When the environment supports it, render and inspect once. Fix observable breakage such as clipping, overlap, distorted media, inaccessible controls, or inert interactions. Keep the handoff concise.