antislop-ui

Files (1)

• SKILL.md

SKILL.md (first lines)

---
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."
allowed-tools: Read Write Edit Glob Grep
---
# 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.
- **The same default family:** harsh or rainbow gradients, purple-and-black schemes, neon or pastel palettes, and blurred radial orbs behind the hero. They are the same tell wearing different clothes: color from the model's default, not from the brand. All of them are FORBIDDEN as defaults without purpose (R-01).

### 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, dot grids, 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.

### Bento Grid

- **Tell:** a section made of a mosaic of differently-sized cards, some spanning two columns or two rows, filling the space like a tiled dashboard.
- **Why:** it is the default "app-like" landing layout of the last few years, so it signals nothing about the product. When every section could be a bento, the layout is a template, not a decision.
- **Fix:** use a bento grid only when the content genuinely has elements of different sizes to show (R-05). If every cell is roughly the same, a simple grid or list is more honest. The RHYTHM dial decides whether sections vary at all.

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

From vedangvatsa/Web3-Jobs, MIT.

More from vedangvatsa/Web3-Jobs