antislop-ui

---
name: antislop-ui
description: UI and visual skill for antislop. Use when building or editing any interface: color, layout, components, motion. Load with the core.
license: MIT
---

# antislop-ui

> Anti Slop: Rules for AI Coding Agents. UI & Visual skill

> Part of the antislop system. Read together with `antislop.md` (the core). This skill deep-dives the UI/visual concern: color, layout, components, decoration, structural flow, and motion. It references core rules by number and never duplicates or renumbers them. Load it when the task builds or edits a website, web app, or any interface.

## How to use this skill

- Load together with `antislop.md` whenever the task is UI or visual work. The core holds the mechanism (the purpose test, the three tiers, the Delivery Gate); this skill holds UI-specific depth.
- Every entry has the same shape: **Tell** (the pattern), **Why** (why it reads as slop), **Fix** (what to do instead), with the governing core rule cited as R-XX.
- The Delivery Gate in the core remains the gate. The "UI Skill Checklist" at the end of this file is the UI-specific supplement to run alongside it.

## Visual & Color

### Generic Blue-Purple Gradient

- **Tell:** blue-to-purple, blue-to-cyan, or purple-to-pink gradients used as the primary color treatment, or a full-page colored glow.
- **Why:** the most over-represented color treatment in training data. It signals "no brand identity", not "our palette", and marks the design as AI-generated at a glance.
- **Fix:** pull the palette from `DESIGN.md` or the product's own identity. Keep a gradient only as a hierarchy function with the reason written down (R-01). A gradient separating one level from another is craft; the same gradient on every section is a default.

### Excessive Glassmorphism

- **Tell:** blur/backdrop-filter on the navbar, cards, modals, and sidebar at the same time.
- **Why:** blur removes texture and sits every surface in the same frosted layer, flattening hierarchy. When every surface is glass, nothing is foreground.
- **Fix:** treat glass as an accent, not a character trait. Dose cap: at most 1-2 elements (R-10). The surface that needs the attention gets the glass; everything else stays solid.

### Excessive Border Radius

- **Tell:** every element is pill-shaped: buttons, inputs, cards, badges, modals.
- **Why:** uniform pill shapes erase the visual language of "this is an input, this is a card". Radius becomes decoration instead of a hierarchy tool.
- **Fix:** set a small set of radii in the design system and apply them deliberately (R-11). One generous radius on the primary CTA reads as intentional; the same radius on every element reads as a default.

### Overly Soft Shadows

- **Tell:** every component carries a large shadow, so the whole page feels like it is floating.
- **Why:** when everything is elevated, elevation communicates nothing. The page loses its ground plane and becomes generic softness.
- **Fix:** use shadow as an elevation marker only, and write the elevation reason down (R-12). Most elements should sit flat; the one or two that need to lift above the page carry the shadow.

### Glow Everywhere

- **Tell:** glow on cards, buttons, icons, badges, backgrounds, and borders simultaneously.
- **Why:** glow is an attention amplifier. Applied everywhere it amplifies nothing, and it is one of the fastest ways to look "made by AI".
- **Fix:** reserve glow for a maximum of 1-2 important elements as a focus accent (R-13). Everything else stays matte.

### Background Grid

- **Tell:** grid squares, blueprint lines, graph paper, or thin repeating lines behind content.
- **Why:** it is a default way to make a flat page feel "technical" without doing any real work. It reads as texture without intent.
- **Fix:** use texture or pattern only when it genuinely supports the product's identity, with the reason written down (R-07). A real identity motif (core Part 3) beats a stock grid every time.

### Dark Mode Default for No Reason

- **Tell:** the whole page is dark simply because it looks "tech", with no branding consideration.
- **Why:** dark is a decision, not a default. Forcing it reads as following a trend, not serving the product.
- **Fix:** choose the theme from brand identity, product type, and audience (R-21). Developer and creative tools have legitimate reasons for dark; a content-first product usually does not. If there is no strong reason for a fixed theme, build a working light/dark toggle.

### Too Many Colors in the Palette

- **Tell:** 5-7 different colors on one page with no clear design system.
- **Why:** a scattered palette has no hierarchy. When every element can be any color, nothing is distinguished.
- **Fix:** cap the active palette at 2-3 core colors + 1 accent (R-29), and let one of the cores be the neutral base. Restraint is what makes the accent land.

### Excessive Accent Color

- **Tell:** one accent color on buttons, icons, badges, links, lines, backgrounds, and glows at once.
- **Why:** the accent stops being an accent the moment it is everywhere. It becomes just another color, and the design loses its focal point.
- **Fix:** the accent belongs at the key moment only (one deliberate accent, core Part 3). Zero accents is sterile; an accent everywhere is slop. Choose the one or two places it matters.

### Sterile Default

- **Tell:** flat white or near-white, thin grey borders, small radius, no texture, generic font, no identity.
- **Why:** this is the "safe" result of over-filtering without direction. It is not slop, but it is not design either: it is a void where a design should be.
- **Fix:** this is a direction problem, not a filter problem. Add `DESIGN.md` or resolve the Design Read (core Part 3), then raise the liveliness dials. The fix is never more bans; it is state the purpose and add energy.

## Layout & Components

### Monotonous Template Layout

- **Tell:** hero, subtitle, 2 CTAs, screenshot, feature grid, testimonials, FAQ, CTA, footer, in that order, every time.
- **Why:** the order is the training-data default, not the product's narrative. Sections appear because the template has them, not because the content needs them.
- **Fix:** build the structure around actual content needs (R-05, C-3). If the product has no testimonials, there is no testimonials section. Section order follows the product's story. Match the RHYTHM dial: if it is 3, sections visibly vary.

### Copy-Paste Feature Cards

- **Tell:** identical size, height, icon, layout, and padding across all feature cards.
- **Why:** uniform cards flatten the content. When every feature is a card with an icon, the features with real weight and the ones without look the same.
- **Fix:** create variation that reflects content hierarchy, with the reason written down (R-14). Not every feature needs to be a card. The flagship feature may deserve a full-width treatment, the supporting ones a list.

### Uniform Spacing

- **Tell:** padding, margin, and gaps are identical across every section.
- **Why:** rhythm is a tool, and a single spacing value removes it. Sections stop relating to each other; the page reads as one flat strip.
- **Fix:** use whitespace as structure (core Part 3) and vary it with the RHYTHM dial. Establish a spacing scale, then use different levels to separate and connect. Uniform rhythm is a deliberate choice only when the dial says so (R-05).

### "How It Works" Always 3 Steps

- **Tell:** round icon + number 1, 2, 3 + short text, always three steps, always the same shape.
- **Why:** the product's real process is rarely a tidy three-step list. The template forces the process into its shape, not the other way around.
- **Fix:** present the process as it actually is (R-05). Three steps with round icons is fine if that is genuinely the process; otherwise use whatever shape the real workflow takes, including two steps or five.

### "Trusted By" Logo Bar

- **Tell:** a row of generic company logos directly below the hero.
- **Why:** it is a trust claim with no evidence: generic logos, no real customers named, no proof of use.
- **Fix:** only show real, verifiable logos (R-18, R-36, C-5). If the product has no such customers yet, do not fabricate a logo bar. Real social proof beats a generic one every time.

### "Most Popular" Pricing Card

- **Tell:** the middle pricing tier always highlighted with a capsule badge.
- **Why:** it is the default pattern, which means it is not a decision. When every pricing section does it, the highlighted tier stops meaning anything.
- **Fix:** highlight the tier that actually serves the product's goals, and write why (R-31). If no tier deserves emphasis, highlight none.

### 4-Column Template Footer

- **Tell:** Product / Company / Resources / Legal columns with no variation.
- **Why:** the columns exist because templates have them, not because the site has that many link groups.
- **Fix:** structure the footer around what the product actually links to (R-05). A single column of links can be more useful than four half-empty ones.

### Uniform Section Rhythm

- **Tell:** every section is centered title + subtitle + identical card grid, with no variation.
- **Why:** identical composition makes sections blur together, and the page feels repetitive and flat.
- **Fix:** vary composition with the RHYTHM dial (R-05). Alternate text-heavy and visual sections, asymmetric and symmetric layouts. A page where every section follows the same template is a page designed by a template.

## Decorative Elements

### Generic AI Icons

- **Tell:** sparkle, star, magic, lightning, diamond, cube, robot, or AI orb as feature icons.
- **Why:** these glyphs are the generic vocabulary of "AI product". They communicate nothing about the specific feature.
- **Fix:** use icons genuinely relevant to the content, with the relevance written down when the glyph is generic (R-04). If no appropriate icon exists, use none. The feature label does the work.

### Emoji as Decoration

- **Tell:** literal emoji scattered through the copy, headings, badges, and buttons: 🚀 in a headline, ✅ beside every feature bullet, 🔥 on a CTA, 📈 above a chart title.
- **Why:** emoji is the loudest shorthand for "this was generated, not written". In a UI it competes with the content for attention and flattens the product's voice into the same cheerful default as every other AI site.
- **Fix:** remove emoji from UI text. If a concept needs a mark, use a real, relevant icon with the reason written down (R-04), or no mark at all. The copy carries the meaning; the emoji adds nothing.

### Small Arrows on Every Button

- **Tell:** `→` or `↗` placed on almost every button as pure decoration.
- **Why:** the arrow becomes a pattern, not a signal. When every CTA has one, none of them point anywhere specific.
- **Fix:** arrows are not the default identity for buttons (R-08). Keep them for the action that genuinely benefits from a direction cue, sized proportionally, with the purpose written down.

### AI Capsule Badges

- **Tell:** pill shape, thin border, glow, small dot, uppercase, containing "AI Powered", "Beta", "New".
- **Why:** the capsule-plus-glow-plus-dot combination is a self-referential badge that says "made by AI, about being made by AI". It adds noise, not information.
- **Fix:** badges only when functionally needed, with the need written down, and never the full combination (R-09). A real status label is fine; a decorative "AI Powered" pill is not.

### Generic AI Typography

- **Tell:** large monospace headings, or uppercase labels with extreme letter-spacing ("HOW IT WORKS", "FEATURES").
- **Why:** monospace-as-aesthetic and wide-tracked uppercase are shorthand for "technical and modern" without doing any real typographic work.
- **Fix:** choose typeface from brand character, not the model's default pick, and write the reason (R-06). Typography must improve readability and reflect the product. A type choice with a reason beats a trend every time.

### Illustrations With No Connection

- **Tell:** Undraw, Storyset, or generic 3D blob characters with no real connection to the product.
- **Why:** decorative illustrations say the design is decorated, not designed. They fill space without serving the content.
- **Fix:** illustrations must have a direct connection to the product, with the connection written down (R-22). If none exists, use real screenshots or no illustration.

## Structural & Flow

### Dead Navigation

- **Tell:** navbar links to pages or sections that do not exist.
- **Why:** dead links are a broken promise. They break trust the moment a user clicks them.
- **Fix:** every navigation item must have a real destination (R-24). If a feature is not built, leave it out, or label it "Coming soon" clearly. The navbar reflects content that actually exists.

### Non-Functional Controls

- **Tell:** buttons do nothing, dropdowns won't open, forms cannot submit.
- **Why:** the visual is finished but the behavior is not. This is the difference between a mockup and a product.
- **Fix:** every interactive element has real behavior, or it is removed (R-26). If an element genuinely cannot have a destination, ship a clear `// TODO` plus a visible "Coming soon" label, or do not ship it.

### Sections That Fill a Template

- **Tell:** a section exists because "every AI landing page has one", not because the content needs it.
- **Why:** template sections are content without purpose. They add length and remove focus.
- **Fix:** every section earns its place from the product's content (C-3). Remove sections that only fill a template. A page with fewer, purposeful sections is stronger than a page with all the defaults.

## App & Dashboard

The patterns above are landing-page shapes. These are the app-side equivalents: the defaults an agent reaches for when the screen is a dashboard, an admin panel, or any signed-in view. The rules they break are the same ones; only the shape is new.

### Default Dashboard Shell

- **Tell:** left sidebar, top bar, four stat cards, a chart, a table. Chosen before anyone asked what the screen is for, and identical whether it manages invoices, patients, or servers.
- **Why:** it is the landing-page template problem in an app: a layout picked from memory instead of from the work the screen supports. Swap the labels and it belongs to any product.
- **Fix:** name the screen's job and the one decision the user makes on it, then build the hierarchy around that (C-3, R-20). If the job is "spot the failing job and retry it", the failing jobs are the page and the stat row is a footnote. Sections that survive only because dashboards usually have them get cut (C-3).

### Stat Cards With Invented Numbers

- **Tell:** a row of four cards reading 12,483 / 94.2% / $48.2K / 1,204, each with a green "+12% this week" delta.
- **Why:** the numbers are decoration, and the deltas are worse: a trend claim with no series behind it. Real dashboards have metrics that matter and metrics that do not, so four equal cards is already a hierarchy failure.
- **Fix:** show real numbers or none (R-17, R-38). Wire the cards to real data, or ship the one metric that is real. A delta appears only when the comparison period is real and named. If the screen is a prototype, label the values as placeholder where the user can see it (R-38).

### Filler Activity Feed

- **Tell:** "Sarah Chen updated a document, 2 hours ago", repeated with rotating names and avatars.
- **Why:** invented people, invented events. It is the testimonial section wearing a different layout, and it makes an empty product look busy.
- **Fix:** the feed shows real events or does not ship (R-18, R-38). An honest empty state beats a fabricated feed, and it tells the user what to do first (R-27).

### Charts Without a Question

- **Tell:** a line or donut chart placed because the space looked bare, with a generic title ("Overview", "Performance") and no axis the reader can act on.
- **Why:** a chart is an answer. Without the question, it is texture, and it costs more attention than a sentence would.
- **Fix:** write the question the chart answers before drawing it, and put that question in the title ("Failed jobs per hour, last 24h"). If a sentence answers it better, write the sentence (C-3). Chart segments still need 3:1 contrast against their neighbours (R-25).

### Generic Table Columns

- **Tell:** Name, Status, Date, Actions, whatever the rows actually are, with a three-dot menu on every row.
- **Why:** the columns come from the table component, not from the data. The user scans for the field that decides their next move and it is not there.
- **Fix:** pick columns from the decision the user makes in this table, and put the deciding field early. The row menu holds actions that exist; anything that does nothing comes out (R-26).

### Filler Data in Fields and Columns

- **Tell:** empty form fields and table columns filled with fake but plausible data: `John Doe`, `johndoe@example.com`, `"Let's build something"`, phone numbers and dates that belong to nobody.
- **Why:** fabricated content disguised as real. It reads fine in a mockup and falls apart the moment a real user looks: the name is not a customer, the email is not a lead, and the message is a tagline. It is the strongest tell that the screen was generated, not built.
- **Fix:** leave empty cells empty, or use placeholders that clearly say what goes there: `Your Name`, `email@example.com`, `Drop your message here...`, or `[REAL DATA]` when a value is expected (R-23, R-38). Real data goes in when it exists. Generic filler copy like "Let's build something" is buzzword slop and does not belong in a data column (R-16).

### Placeholder Empty and Loading States

- **Tell:** "No data available" with an illustration, a bare spinner, or a full-page skeleton that mimics a layout the real data never fills.
- **Why:** R-27 requires the states, and these technically have them. They still tell the user nothing: no cause, no next action, no idea whether this is normal.
- **Fix:** an empty state says why it is empty and gives the one action that fills it ("No jobs yet. Run a sync to see results here"). A loading state says what it is loading. An error state says what failed and what to do next (R-27). First run, filtered to nothing, and permission denied are different screens and read differently.

## Motion

### Endless Pulses and Loops

- **Tell:** elements that pulse, bounce, or float forever with no user trigger.
- **Why:** perpetual motion is noise. It competes with the content for attention and never stops to let the user rest.
- **Fix:** motion must have a clear UX purpose, written down (R-19). Animation guides attention to a moment; it does not run on a loop. If the MOTION dial is 1 (hover states only), an endless loop is a FAIL against the declared dial.

### Template Animations Stacked

- **Tell:** every element uses Fade Up + Fade In + Floating + Scale + Bounce simultaneously.
- **Why:** a page where everything animates has no focal point. Motion becomes wallpaper.
- **Fix:** choreograph motion to a purpose and to the MOTION dial (R-19). Not everything moves. The hero speaks, the supporting elements stay calm. Claimed "cinematic" pages must actually move; claimed "static" pages must not.

## UI Skill Checklist

Run these alongside the core Delivery Gate when the task is UI work. All answers must be **yes**:

- [ ] Is the palette derived from `DESIGN.md` or a written brand identity, not the default gradient set? (R-01, R-29)
- [ ] Is the accent used at the key moment only, not spread across every element? (core Part 3, one deliberate accent)
- [ ] Is the copy free of decorative emoji scattered through headings, bullets, and buttons? (R-04)
- [ ] Do section compositions vary according to the declared RHYTHM dial instead of repeating one template? (R-05)
- [ ] Does every navigation item and interactive element have a real destination or behavior, or a visible "Coming soon" label? (R-24, R-26)
- [ ] Does motion follow the declared MOTION dial and serve a written purpose, with no endless loops? (R-19)
- [ ] Is glass, glow, shadow, and radius used at their dose caps, not as a page-wide default? (R-10, R-11, R-12, R-13)
- [ ] On an app screen, is the layout built around the decision the user makes there, rather than the sidebar plus stat row plus chart plus table default? (C-3, R-20)
- [ ] Is every number, delta, feed entry, and table row real or a labelled placeholder, with no invented metrics? (R-17, R-18, R-38)
- [ ] Do empty form fields and table cells stay empty or carry honest placeholders (Your Name, email@example.com) instead of fake-looking data (John Doe, johndoe@example.com)? (R-23, R-38)
- [ ] Do the empty, loading, and error states name the cause and the next action instead of saying "No data"? (R-27)
- [ ] Does the page hold up at every breakpoint, theme, and state, and pass keyboard-only use? (R-03, R-34, C-4)