| name | unslop-ui |
| description | Strips the cues that make a website read as AI-generated and forces a deliberate, project-specific design choice instead of the model's default. It does not impose a look or hand you taste. It removes tells (default shadcn/Tailwind, AI-purple gradients, gradient heading text, unprompted neon glow, emoji-as-icons, the centered hero plus three feature cards) AND the newer cream-plus-serif-plus-sage "tasteful default" that trading one default for another creates. Grounded in a 47-subreddit, 3.2M-post Reddit analysis of what people flag as AI slop. Use whenever building, styling, reviewing, refactoring, or auditing any website, landing page, web app UI, dashboard, or front-end component, especially when the user wants a site to look custom or human rather than AI-generated, or mentions AI slop, looks AI-made, generic, vibe-coded, Tailwind, or shadcn. Trigger even if they never say vibe-coded. |
unslop-ui
Read this first, because the most common misunderstanding sinks the whole thing.
This skill does not give you a good design, and it does not have a preferred look.
It does two narrow things. It removes the specific cues that make a site read as
AI-generated, and it forces a deliberate, project-specific choice where the model would
otherwise reach for its default. Taste, brand, and layout judgment are still yours. A
guardrail is not a designer.
The trap to avoid (this is the whole point)
The failure mode of every anti-slop effort is replacing one default look with another.
The 2024 tell was the purple-to-blue gradient on a dark hero. The 2026 tell is a warm
cream background with a serif display font (Instrument Serif, Fraunces) and a sage or
forest green accent, which is the current Claude/Anthropic house style. Swapping the
first for the second is not unslopping. It just resets the clock, and people clock it
just as fast.
So this skill never prescribes a palette, a font, or a layout. Prescribing one is how
you become next year's slop. What it does instead: detect the defaults (old AND new),
and require that any replacement be a specific choice the user or project actually made,
not the model's next-most-likely guess. The only universal rule here is "make a
deliberate choice and be able to say why," which is the one thing a default never is.
If the user genuinely wants purple, neon, a serif, or a cream background as a real brand
decision, that is not slop and the skill leaves it alone. A tell is an unspecified
default, not a banned color. Honor unslop-ignore (see Audit mode) for anything chosen
on purpose.
How this differs from the built-in frontend-design skill
Claude already ships a frontend-design skill, and it is good, but it produces the cream
- serif + green house look that this skill now flags as a tell. unslop-ui is
complementary and adds three things that one does not: a deterministic scanner you can
run in CI (exit code gates a build), a data-grounded ranking so effort goes where real
complaints are, and an explicit check against the new "tasteful default" so you do not
launder slop into a different slop. Use both. Let the design skill build; let this one
keep it honest.
Mode 1: Build (the important one)
Most "looks AI" outcomes are a specification problem, not a styling problem. An
unspecified prompt gets the median of the training data, and everyone's median is
identical. So before generating any UI, establish the brief. Either pull it from the
user, or if they have not given one, state the choices you are making and why, then
proceed. Do not silently fall back to defaults.
Establish, concretely:
- A reference. One real site, screenshot, brand, or product whose design language to
follow. This single input does more than every other rule combined. If the user has
one, anchor to it. If not, ask for or pick a specific named direction (editorial,
brutalist, utilitarian-dense, warm-consumer, technical-mono, and so on), not "modern
and clean," which means nothing.
- A color decision. A real brand color or a deliberately chosen one, stated. Not the
framework default, and not the cream/sage default either.
- A type decision. A specific typeface or pairing chosen for this project, with a
reason. Avoid the top-50 defaults reached for on autopilot (Inter, Geist on the sans
side; Instrument Serif, Fraunces, Playfair on the "tasteful" side) unless they are a
real choice.
- A layout intent. What the page is actually for and what the user should do first,
which determines structure. This is how you avoid the hero + three-card skeleton: the
structure follows the goal, not a template.
When the user gives no brief and wants you to just build, do not produce one median
result. Produce a deliberate one and say what you chose, or offer two or three genuinely
distinct directions. The value is breaking the monoculture, so vary away from the
center on purpose.
Then, while building, avoid the specific tells in references/tells.md.
references/choosing-a-look.md is a process for making the
color/type/layout choices deliberately, written as a method rather than a prescription,
precisely so it does not become the next default.
Mode 2: Audit (the guardrail)
When reviewing or cleaning existing code, or when the user says "does this look AI,"
"de-slop this," "make it not look vibe-coded," run the scanner first, then fix in
priority order.
python3 scripts/devibe_scan.py <path>
python3 scripts/devibe_scan.py <path> --severity high
python3 scripts/devibe_scan.py <path> --json
It scans .html .css .scss .js .jsx .ts .tsx .vue .svelte .astro, reports each finding
with file, line, and fix, and gives a vibe score. Exit code is the high-severity count,
so CI can gate on it. The scanner catches the mechanical tells (colors, fonts,
gradients, the cream+serif combo). It cannot see layout coherence, spacing consistency,
or whether text overflows its container, and those are also what make a site read as AI,
so after the scan, check those by eye against the catalog.
Respecting intentional choices. A line with the comment unslop-ignore is skipped.
Use it when a flagged value is a real decision, so the audit stays trustworthy and does
not nag about a chosen brand color.
Fixing well. Do not fix bg-purple-600 by swapping in bg-emerald-700, which is
just a different default. Fix it by applying the project's actual color, or by asking
what the color should be. A fix that introduces a new unspecified default is not a fix.
What this deliberately does not flag
Grounded in the data, not vibes. Mesh, aurora, and blob backgrounds barely register as
real complaints (mostly a keyword artifact). Bento grids and glassmorphism are low and
contested. Dark mode itself is fine; only unprompted glow is a tell. shadcn and Tailwind
themselves are fine; their untouched defaults are the tell. Over-flagging trains people
to ignore the tool, so the scanner stays narrow.
Reporting an audit
Lead with the verdict and the single highest-impact change. Then findings by priority
with file:line and the fix. Close with the vibe score and the top three changes. Plain
and specific. The goal is a site that looks like a person made a decision, which is the
one thing the scanner cannot do for them.
