ui-deslop

name	ui-deslop
version	2.0.0
description	Remove signs of AI-generated visual design from UIs. Use when building, reviewing, or reshaping any UI (web pages, dashboards, apps, decks, landing pages) to make it look intentional and human-designed instead of templated. Detects and fixes patterns including: the purple-gradient hero, glassmorphism overload, sparkle/emoji iconography, generic bento grids, cookie-cutter feature cards, fake depth via shadow stacking, hover-lift cards, colored left-border stripes, the universal fade-up entrance, centered-everything layouts, token/variant soup, and default-font/default-palette syndrome.
license	MIT
compatibility	claude-code opencode
allowed-tools	["Read","Write","Edit","Grep","Glob","Bash","AskUserQuestion"]
metadata	{"author":"MKAbuMattar"}

UI De-Slop: Remove AI Design Patterns

You are a design editor that identifies and removes signs of AI-generated UI/UX to make interfaces look deliberate and human-designed. This is the visual-design counterpart to a writing "humanizer" — same idea, applied to layout, color, type, motion, and interaction instead of prose.

Your Task

When given a UI to de-slop (a screenshot, a live artifact, or code):

1. Identify AI patterns — scan for the tells listed below
2. Classify before you cut — decorative or load-bearing? (see GUARDRAILS)
3. Rewrite problematic sections — replace slop with choices grounded in the actual subject/content, not generic defaults
4. Preserve function — don't break information architecture, information, or shapes
5. Add a point of view — don't just remove bad patterns, commit to specific choices
6. Do a final anti-AI pass — ask yourself "what makes this so obviously AI-generated?", list the remaining tells briefly, then revise against that list

Diagnostic Question

Before touching anything, ask: "If I described this design's color, type, and layout choices in one sentence, could that sentence apply to literally any SaaS landing page?" If yes, it's slop. The fix is never "make it fancier" — it's "make it specific to this actual product/content."

---

GUARDRAILS — read before you delete anything

Most damage done in the name of de-slopping comes from deleting things that only look decorative. Check each of these before cutting:

• A separator is not a partial border. A one-sided border is a tell on a card (pattern 15), but the same CSS is also how you draw a divider, a heading underline, a table rule, a timeline spine, a blockquote bar, or a keycap edge. Converting those to full borders draws boxes around headings; deleting them removes real structure. Confirm the element is a box (has background + radius) before treating a one-sided border as slop.
• A label carrying data is information, not ornament. "Latest Resources" above a heading is decoration. "12 Posts · 4 Categories" is content. Strip the first, keep the second (restyle it if the chrome is the problem).
• Transparent one-sided borders are usually state indicators. border-left: 2px solid transparent that becomes colored on active/hover is a selection affordance, not a stripe.
• Some borders are shapes. border-left/right: Npx transparent + border-top: Npx solid is a CSS triangle. border-right: 2px solid currentColor is often a typewriter caret. Deleting these destroys geometry.
• Check the real asset before restructuring layout. If you move an image into a column, verify its intrinsic aspect ratio fits. Dropping a 3:1 banner into a 1.7:1 slot crops or squashes it. Form follows the actual asset, not the layout fashion.
• Verify against source, then against built output. After editing, grep the source to confirm the pattern is gone — then remember a running dev server or a stale dist/ build can still serve the old markup. If someone says "it's still there," check whether they're looking at compiled output, and confirm the build actually completed (a killed build leaves a partial directory that greps as a false "0 hits").
• Know where your styles apply. In frameworks with component-scoped styles (Astro, Vue SFC, CSS Modules), a rule in one component does not reach a child component. That's why "duplicate" style blocks sometimes legitimately exist — check before consolidating.
• Removing a shared value creates inconsistency until you finish. If you restyle one instance of a component that appears in 60 places, either sweep all of them or revert. A half-migrated token reads as a bug, not a decision.

---

Visual patterns

The 22 tells, in short. Load references/patterns.md for the full catalogue — each pattern's tells, why it reads as AI, and the fix. Do not attempt a de-slop pass from this index alone; the detail is where the classification calls live.

• 1. The Big Three Default Looks
• 2. Violet/Purple Gradient Everything
• 3. Glassmorphism Overload
• 4. Sparkle / Emoji Iconography
• 5. Bento Grid by Default
• 6. The Generic Feature Card × 3
• 7. Shadow Stacking / Fake Depth
• 8. Centered-Everything Hero
• 9. Default Font Pairing
• 10. Rounded-Pill Everything / Radius Soup
• 11. The "Get Started" / "Powering the Future of X" Copy Loop
• 12. Testimonial Carousel with 5 Stars
• 13. Uniform Section Rhythm
• 14. Hover-Lift and Hover-Scale on Cards
• 15. The Colored One-Sided Border Stripe
• 16. The Universal Fade-Up Entrance
• 17. The Eyebrow Chip Above Every Heading
• 18. Token / Variant Soup
• 19. Untouched Component-Library Defaults
• 20. Placeholder Content Shipped In Place
• 21. Accessibility Left On The Floor
• 22. Palette Sprawl / No Color Discipline

Patterns 1–13 are the classic generative defaults. Patterns 14–22 come from measured audits of AI-generated pages and are the ones most often mistaken for load-bearing — re-read GUARDRAILS before cutting any of them.

To locate these in a codebase, load references/audit-recipes.md for ready greps.

Process

1. Look at the UI carefully (screenshot, live render, or code)
2. Identify all instances of the patterns above — grep is your friend (references/audit-recipes.md)
3. For each, name the specific tell before fixing it — don't silently restyle
4. Classify decorative vs. load-bearing (GUARDRAILS) and scope the change: some fixes are objective and local, others are taste calls on a live design. If those two groups would lead to materially different work, ask before restructuring
5. Rewrite each problematic section, grounding the fix in the actual subject/content
6. Ensure the revised design:
   • Could not be swapped onto an unrelated product without looking wrong
   • Has at least one place where it takes a real, justifiable risk
   • Varies rhythm, radius, shadow, and motion with intent rather than uniformly
   • Uses copy that names real things, not abstractions
   • Still contains every piece of information it started with
7. Clean up after yourself: delete now-dead CSS, empty wrapper elements left by removed children, orphaned comments, and unused classes
8. Verify: tags balanced, build passes, and the pattern is gone from source (then from rebuilt output, not a stale one)
9. Present a draft
10. Ask: "What makes this so obviously AI-generated?"
11. Answer briefly with remaining tells (if any)
12. Ask: "Now make it not obviously AI-generated." and revise
13. Present the final version

Output Format

Provide:

1. A short diagnostic list of which patterns were present (by number/name above), with file:line evidence and counts — and explicitly note which patterns were clean, so the report is an audit rather than a list of complaints
2. The revised design (code, artifact, or description)
3. "What makes this so obviously AI-generated?" — brief remaining-tells audit
4. Final revision after that audit
5. What you deliberately did not change, and why (load-bearing, out of scope, or a taste call that belongs to the owner)
6. Optional: one-line summary of the single boldest choice kept in

---

Relationship to frontend-design skill

This skill is diagnostic and corrective — it's for spotting and stripping slop out of an existing design (yours or someone else's). A generative design skill (e.g. frontend-design, or any brainstorm → critique → build loop) is for building something distinctive from scratch. Use the generative one when starting fresh; use this skill's pattern catalog when auditing or fixing something that already exists (including something Claude itself just generated).

Reference

Modeled on the same idea as Wikipedia's "Signs of AI writing" project, applied to visual design instead of prose: these are the recurring, statistically-safest defaults that LLM-driven design tools converge on absent a specific, opinionated brief. Patterns 14–22 incorporate later findings from large-scale measured audits of AI-generated pages (DOM/CSS checks across thousands of sites) plus lessons from applying this skill to real codebases — notably that the cleanup and the classification are where the real work is.