| name | anti-ui-slop |
| description | Stop UI slop before it ships. Use when building or reviewing React, Next.js, web, and iOS interfaces that need product-specific hierarchy, states, responsive decisions, and a hard finish gate grounded in UIZZE's 800,000+ real screens. Trigger with "stop UI slop", "review this UI", or "make this interface product-specific". |
| argument-hint | [screen, route, component, or screenshot] |
| allowed-tools | Read,Write,Edit,WebFetch,Bash(npm:*),Bash(npx:*),Bash(pnpm:*),Bash(yarn:*) |
| version | 1.1.0 |
| author | UIZZE <business@uizze.com> |
| license | MIT |
| compatibility | Designed for Claude Code, Codex, Cursor, Copilot, and other Agent Skills-compatible coding agents |
| tags | ["ui-design","frontend","design-systems","code-quality","anti-slop"] |
STOP UI SLOP.
If your UI looks generated, you have already lost the first impression.
Overview
Use this skill to replace interchangeable interface defaults with a product-specific design language grounded in real interface evidence. The free workflow uses UIZZE's public catalogue, a design contract, explicit interaction states, responsive decisions, and a hard finish gate. It works without an account, token, MCP connection, bundled script, executable, or dependency.
Prerequisites
- Read access to the target repository, product intent, and existing design system.
- Write access only when the user has asked for implementation or fixes.
- A rendered interface, local preview, or screenshots for the final review when available.
- Access to the public catalogue at https://uizze.com, or two or three UIZZE links or screenshots supplied by the user when browsing is unavailable.
Do not require an account or MCP connection for the free workflow.
Instructions
Step 1: Inspect the Product
Use Read to identify the primary user, screen job, primary action, content hierarchy, required states, existing components, semantic tokens, and platform constraints. Preserve intentional product decisions already present in the repository.
Step 2: Gather Interface Evidence
Use WebFetch to search the public UIZZE catalogue for relevant screens, flows, and elements when web access is available. Extract transferable decisions about hierarchy, workflow shape, density, typography, navigation, controls, state behavior, and responsive treatment. Never copy branding, proprietary text, imagery, or an exact layout.
Step 3: Write the Design Contract
State the screen job, hierarchy, allowed components, required states, responsive behavior, product-specific decisions, forbidden generic patterns, and verification criteria. Keep one clear primary action and make every major element support the screen job.
Step 4: Implement in the Product Language
Use Edit for existing files and Write for new files only when implementation is authorized. Keep the repository's existing components and tokens. Replace filler metrics, vague copy, decorative gradients, equal-weight card grids, inert controls, and arbitrary badges with content and interactions specific to the product. Implement loading, empty, error, disabled, success, and recovery states required by the flow.
Step 5: Verify the Rendered Result
Render the interface at the relevant viewport sizes. Exercise the primary flow and every required state. Use only the scoped package-manager Bash commands declared by this skill to run focused checks. Do not invent runtime behavior, user research, analytics, or hidden states.
