anti-ui-slop✓ Pass

SKILL.md Content

---
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:

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

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:

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.

License

Declared license: MIT

MIT License

Copyright (c) 2025 github

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

View the license in the source repository — the version published there is authoritative.