| 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. |
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.
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:
- the screen or flow and its source link;
- the structural decision worth transferring;
- why that decision fits this product;
- 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
Before changing code, write a short contract with these fields:
| 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 |
The contract must name concrete choices. “Clean,” “modern,” “intuitive,” and “premium” are not design decisions.
4. Build in the Product’s Language
- 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.
5. Run the Finish Gate
Render the result at every supported breakpoint and block completion when any item fails:
Product specificity
- 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?
Interaction completeness
- 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?
Responsive and accessible behavior
- 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?
Design-system integrity
- 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?
Fix every blocking failure and re-run the gate before declaring the UI complete.
6. Handoff Format
Report the finished work in this order:
- Evidence: the references and decisions that influenced the result.
- Contract: the final product-specific design rules.
- Implementation: the meaningful interface and behavior changes.
- Verification: breakpoints, interaction states, and accessibility checks performed.
- Remaining risks: anything that could not be verified, without overstating completion.
