Anti-AI-slop design and copy rules for any UI work (website, web app, or interface). Use whenever building, refining, or auditing user-facing UI. Holds every visual decision to a purpose test and the result to a liveliness bar so the output feels crafted by a designer, not generated by AI. Two modes: DURING (apply rules while building) or AFTER (audit finished work with a numbered findings list). Pairs with a DESIGN.md / brand direction for identity. Complements hallmark, taste-skill, baseline-ui, and improve-ui.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Anti-AI-slop design and copy rules for any UI work (website, web app, or interface). Use whenever building, refining, or auditing user-facing UI. Holds every visual decision to a purpose test and the result to a liveliness bar so the output feels crafted by a designer, not generated by AI. Two modes: DURING (apply rules while building) or AFTER (audit finished work with a numbered findings list). Pairs with a DESIGN.md / brand direction for identity. Complements hallmark, taste-skill, baseline-ui, and improve-ui.
license
MIT
metadata
{"version":"1.0","source":"miqdadbadjuber/anti-slop (MIT)","port":"clean methodology-only port of upstream antislop.md (no scripts, no deps)","relates":"hallmark, taste-skill, baseline-ui, improve-ui, huashu-design"}
antislop
Anti AI Slop: Design & Copy Rules
Follow these rules whenever generating or building UI for a website, web app, or any interface.
The goal: the design should feel crafted by a designer, not generated by AI.
Before any UI work, ask the user (in their chat language) when antislop applies: during the work, or after it is done. Do not start until they answer.
Two Usage Modes
antislop is used one of two ways. At the start of a session, ask the user which applies, in the user's chat language (not the language of this file). Do not start UI work until they answer.
When do you want to use antislop?
DURING the project, while working (planning & execution). I will apply the rules while I write, so AI slop does not appear from the start.
AFTER the project is finished. I will audit what exists: a numbered findings list with priorities, you pick which numbers to fix, then I fix and report.
Which one, 1 or 2?
Mode 1 (During): follow the rules while generating. This prevents slop from the start and ends with the Delivery Gate. Use it when building new UI.
Mode 2 (After): audit an already-finished project. Produce a numbered findings list in anti-slop/audit-001-YYYY-MM-DD.md (numbers keep rising). Each finding cites the violated rule (R-XX) and a one-line reason. Priority follows the rule tier: Hard Gate = HIGH, Purpose-Gate = MEDIUM, Quality Locks = LOW. Do not modify anything until the user approves specific numbers; numbers not mentioned are not touched. Then fix the approved items and write a follow-up report.
What This Is (and What It Isn't)
antislop.md is a filter, not a style guide. It stops AI coding agents from producing generic, recognizable "AI slop" UI, without falling into the opposite failure: a sterile, lifeless default.
This document does not impose an aesthetic: no prescribed colors, fonts, layouts, or "house style".
This document does not ban visual techniques (gradients, glassmorphism, badges, card grids). Those are tools. What it rejects is technique without purpose.
This document does two things only:
Holds every visual decision to a purpose test: what does this technique serve? Write the reason down.
Holds the result to a liveliness bar: the output must be alive and specific, not just "clean". See Part 3.
antislop.md is one of three files, and it is a filter, not a source of direction:
DESIGN.md (or your brand/style direction) gives the design its soul: identity, personality, palette, typography, mood. This is what makes a result feel alive and specific. How you fill it is your business: write it yourself, or build it from visual references you like.
AGENTS.md (or CLAUDE.md, GEMINI.md, etc.) routes the agent: "for UI work, read DESIGN.md for direction, then antislop.md as the filter."
antislop.md rejects slop and requires liveliness. It does not invent direction; the Design Read (Part 3) turns a brief into dials.
Removing slop does not reveal good design; it leaves a void. Liveliness must be added, not assumed. A sterile result means either direction was missing or liveliness was not added, and both are failures to fix. The fix is never "add more bans"; it is "state the purpose and raise the liveliness bar".
Core Principle
The filter rejects technique without purpose, not technique itself. Before using any visual technique, answer: what does this serve? If the only answer is "it looks AI" or "it looks safe", the technique must go or be reworked. If the answer names a hierarchy, identity, or readability goal, it stays, and the reason is written down.
The question to answer before calling anything done:
If the logo and product name were swapped out, would this design still feel unique and have its own character?
If the answer is no, the design is too generic. Start over.
A design is done only when all three are true:
Every technique passes the purpose test (see the Purpose-Gate group in Part 2).
It has its own identity and character (see Part 3: Liveliness Toolkit).
It actually works (see The Craftsmanship Standard).
The Craftsmanship Standard
"Not slop" is the floor, not the goal. A design passes when it meets five preference-agnostic criteria. Use these as questions, not recipes.
C-1 — Intentionality
Every visual and copy decision has a reason you can articulate. If the only reason is "it's the AI default", that is a red flag: revisit the decision.
C-2 — Functional Completeness
Every interactive element works, or it does not exist. A button that cannot do anything is a defect, not decoration.
C-3 — Content-Driven Composition
Every section exists because the product's content needs it, not because every AI landing page has one. Remove sections that only fill a template.
C-4 — Resilience
The UI holds up in every state (empty, loading, error), every theme you ship, every breakpoint, and keyboard-only use.
C-5 — Evidence Over Claims
Anything presented as fact (testimonials, statistics, security claims) is real and verifiable, or it is not shown at all.
Part 1: AI Slop Patterns (Warning Signs)
These are the most common patterns found in AI-generated designs. Use this table to audit your output: scan for clusters, then ask each one "what does this serve?" A single pattern from this list is fine if it serves a purpose, unless a Hard Gate rule in Part 2 forbids it (R-02, R-17, R-18, R-23 to R-28, R-32 to R-38). What makes a design slop is many of these appearing together with no reason. This is a diagnostic scan, not a ban list: Part 1 itself bans nothing, but the Hard Gate rules in Part 2 are absolute, and every other pattern must pass the purpose test (Part 2, Purpose-Gate group).
Visual & Color
Pattern
Telltale Signs
Generic Blue-Purple Gradient
Blue to Purple, Blue to Cyan, Purple to Pink, full-page colored glow background
Excessive Glassmorphism
Blur on navbar, cards, modals, sidebar all at once
Excessive Border Radius
Every element is pill-shaped: buttons, inputs, cards, badges, modals
Overly Soft Shadows
Every component has a large shadow, the whole page feels like it's floating
Glow Everywhere
Glow on cards, buttons, icons, badges, backgrounds, and borders all at once
Large monospace headings, HOW IT WORKS uppercase with wide tracking
Typeface Chosen Without Reason
Font picked because it's the AI default, not because it fits brand character. Popular fonts like Inter are still valid if there's a reason
Generic Illustrations
Undraw, Storyset, or 3D blob characters with no real connection to the product
Functionality & Content
Pattern
Telltale Signs
Non-Functional Interactive Elements
Buttons do nothing, dropdowns won't open, forms can't be submitted. AI builds the visuals but forgets the logic
Happy Path Only Design
No empty state, loading state, or error state. UI looks perfect in screenshots but isn't ready for real use
Irrelevant FAQ
FAQ contains generic template questions ("Is my data secure?", "Can I cancel anytime?") with no real relevance to the product
Assumed Logo & Profile Photos
Creating app logos, avatars, or profile photos without explicit instructions, generated purely on assumption
Navbar Links to Nowhere
Navbar contains links to pages (Features, Contact, About, etc.) that have no actual section or page
File/CSS Patching via Script
A feature (e.g. dark mode) added by an external script that rewrites source or CSS with string replacement. Signs: a .py/.js helper doing str.replace on .css files, "patch" scripts left in the repo
Identity & Originality
Pattern
Telltale Signs
No Visual Identity
Swap the logo and the design still feels the same; could belong to any product
Clone of Popular Products
Overall visual that mimics Linear, Vercel, Stripe, Notion, or other popular products without being asked
Accessibility
Pattern
Telltale Signs
Poor Color Contrast
Grey text on grey background, white text on a gradient that's light in some areas. Looks fine visually but fails WCAG
Not Keyboard Navigable
UI can only be used with a mouse. Interactive elements can't be reached with Tab, no visible focus state
Part 2: Mandatory Rules (R-01 to R-38, grouped)
All 38 rules still apply. They are grouped into three tiers so the mechanism is explicit: Hard Gate rules are absolute, Purpose-Gate rules allow the technique but require a written reason, Quality Locks are consistency requirements.
Group 1: Hard Gate (absolute, no exceptions)
These rules protect honesty, function, and accessibility. Breaking any of them is a FAIL regardless of purpose.
R-02 — Copywriting
FORBIDDEN: em dash character (—) in any text
Use comma (,), period (.), colon (:), or parentheses () instead
Text must feel natural and human
R-03 — Mobile Responsiveness
REQUIRED: mobile layout must be perfect, not an afterthought
No horizontal overflow
Text does not escape its container
Cards do not collide or clip off-screen
Navbar remains comfortable to use
Button sizes meet the minimum tap target (44px)
Spacing stays consistent across all breakpoints
Responsiveness is part of the design, not an add-on.
R-17 — Data & Numbers
FORBIDDEN: numbers and statistics without a real source
If real data is not available, display no numbers at all
Empty is better than deceptive
R-18 — Testimonials
FORBIDDEN: AI avatars, random names, random job titles, fictional reviews
If you have no real testimonials, do not create a testimonials section
Use social proof that can be verified
R-23 — Clarification & Visual Assets
REQUIRED: before creating any asset without explicit instructions, ask or use a clear placeholder
If there is an opportunity to ask, confirm the following first:
App logo or icon (shape, color, concept)
Avatars, profile photos, or images representing people/team
Statistics and numbers to be displayed
Names, job titles, or identities in testimonials
Navigation structure and desired page layout
If asking is not possible (rapid prototyping, limited context): use clear placeholders and do not disguise them as final
Logo: product name as text in an appropriate typeface, or the marker [LOGO]
Profile photo: initial-based avatar or a simple geometric placeholder
Statistics: not displayed, or marked [REAL DATA]
Never generate assets as if they are the final version without confirmation
If explicit instructions already exist, generate directly without asking again
R-24 — Navigation
FORBIDDEN: placing links in the navbar for pages or sections that do not exist in the design
Every navigation item must have a real, accessible destination
If a feature has not been built yet, do not include it in the navbar, or clearly label it as coming soon
The navbar must reflect the structure of content that actually exists
R-25 — Color Contrast
REQUIRED: all text must meet the minimum WCAG AA contrast standard
Normal text: minimum contrast ratio of 4.5:1
Large text (18px+): minimum contrast ratio of 3:1
FORBIDDEN: light grey text on a grey background
FORBIDDEN: white text on a gradient that is light in some areas
Always test contrast across the entire area the text passes over, not just at a single point
R-26 — Interactive Elements
Every interactive element must have a real behavior, or be removed:
A link or button that scrolls to an existing section (real href="#...")
A modal or dialog that opens and closes (closable with Escape)
A state toggle (mobile menu, theme, accordion, tabs)
An external action (mailto:, a real product URL)
A form that submits and shows feedback
FORBIDDEN: buttons and links that do nothing
FORBIDDEN: nav items pointing to sections that do not exist (see R-24)
If an element genuinely cannot have a destination yet, remove it instead of shipping a dead control. A placeholder is acceptable only with a clear // TODO comment in code AND a visible label to the user (e.g. "Coming soon"). See "Functional Patterns" below.
R-27 — UI States
REQUIRED: every UI that displays data must have at least three states:
Empty state: the view when there is no data yet
Loading state: an indicator while data is being fetched
Error state: the view when something goes wrong
A UI designed only for the ideal condition is not ready for real use
These states are not bonuses; they are part of a complete design
R-28 — FAQ
FORBIDDEN: FAQ containing template questions that are not specific to the product
Every question in the FAQ must address a real concern of that product's users
If you do not know what questions are actually asked, do not create an FAQ section
A generic FAQ does more damage to trust than having no FAQ at all
R-32 — Keyboard Accessibility
REQUIRED: all interactive elements must be reachable and operable by keyboard
Tab and Shift+Tab navigation must work logically following visual order
Buttons and links must be activatable with Enter or Space
Dialogs and modals must be closable with Escape
REQUIRED: every focused element must have a clearly visible focus indicator
FORBIDDEN: removing the focus outline with outline: none or outline: 0 without replacing it with a better custom focus indicator
A UI that can only be used with a mouse is an unfinished UI
R-33 — No File/CSS Patching via Scripts
FORBIDDEN: implementing or altering UI features by running an external script that rewrites source files or CSS with string replacement
Build features directly in the source code where they belong
A feature added by a patch script (e.g. a Python script editing .css files) is broken by design and must be rewritten in source
R-34 — Every Theme You Ship Must Work
If you ship a theme toggle, BOTH modes must be fully functional
Contrast, colors, and every component must be verified in each mode
FORBIDDEN: shipping a mode where base styles, fonts, or layout break
R-35 — Verify Before You Deliver
Run or build the app before declaring the task done
Check the console for errors
Exercise every interactive element
Check every theme and the mobile breakpoints
A design that has never been run is not finished
R-36 — No Fabricated Claims
FORBIDDEN: inventing security, compliance, or performance claims ("SOC 2 compliant", "ISO 27001", "300% faster") without real evidence
FORBIDDEN: fake testimonials, fake statistics, fake names (see R-17, R-18)
If there is no real data, show no claim
R-37 — Design Direction Required
Before building a UI, load the style direction: DESIGN.md or explicit brand guidance from the user
If no direction exists, ask the user, or state clearly that the design was built without direction and is a draft, not a deliverable
If no direction exists AND the user cannot be asked, the output MUST be labeled "draft without direction" AND use the honest default dials ENERGY 1 / RHYTHM 1 / MOTION 1 (see Part 3). Never silently fall back to a neutral, sterile default
FORBIDDEN: designing without direction and silently falling into a neutral, sterile default
Style direction is the product owner's identity, not a slop pattern; this filter only applies on top of it
A design built without direction is a draft, not a shippable result
R-38 — Real Content or Honest Placeholder
Every claim, feature, testimonial, statistic, nav item, or visual element must come from real information OR be an explicitly labeled placeholder
FORBIDDEN: fabricating content that looks realistic (fake testimonials, invented features, fake statistics, ghost links, fictional team or people)
Placeholders are written as what they are: [REAL DATA], "Coming soon", never disguised as final (see R-23)
An empty section is better than a fabricated one
Group 2: Purpose-Gate (technique allowed, purpose required)
Each technique below is allowed. It FAILS only when it appears as a default without a stated purpose, or when the reason for it is not written down. Every rule has the same shape: FORBIDDEN as default without purpose; ALLOWED when it serves hierarchy/identity and the reason is written; dose caps for the excessive cases.
R-01 — Color & Gradients
FORBIDDEN as default without purpose: blue-to-purple, blue-to-cyan, purple-to-pink gradients as primary colors, colored glow backgrounds, neon blue buttons
ALLOWED when the color/gradient is part of an established brand identity OR serves a stated hierarchy goal, with the reason written down
A gradient that separates one level of hierarchy from another is craft; the same gradient covering the whole page is slop. The technique is not the problem, the purpose is
R-04 — Icons
FORBIDDEN as default without purpose: Sparkle, Star, Magic, Lightning, Diamond, Orb, Robot as feature icons
Icons must be genuinely relevant to the content they represent, and the relevance written down when the icon is a generic glyph
If no appropriate icon exists, it is better to use none
R-06 — Typography
FORBIDDEN as default without purpose: large monospace fonts used purely for "terminal" aesthetics, uppercase labels with extreme letter-spacing (HOW IT WORKS, FEATURES)
Choose typeface based on brand character, not because it is the AI model's default pick, and write the reason
Typography must improve readability and reflect the product's character
R-07 — Background
FORBIDDEN as default without purpose: grid squares, blueprint lines, graph paper as a background
Use texture or pattern only if it genuinely supports the product's specific visual identity, with the reason written down
R-08 — Button Arrows
Arrows (→, ↗) are not the default identity for every button
If used, ensure the size is proportional and serves a clear visual purpose, and write that purpose down
Not every CTA needs an arrow
R-09 — Badges
FORBIDDEN as default without purpose: capsule badges containing "AI Powered", "Beta", "New", "Secure", "Fast" without context
Badges may only be used if functionally needed (a real status or real label), with the need written down
Avoid combining: capsule + thin border + glow + small dot + uppercase all at once
R-10 — Glassmorphism
Glassmorphism is an accent only, not the character of the entire UI
Dose cap: blur/backdrop-filter on at most 1-2 elements; FORBIDDEN on navbar, cards, modals, and sidebar simultaneously
R-12 — Shadow
Shadow must support visual hierarchy, not make every element float
Use shadow selectively as an elevation marker, not as a default for every component, and write the elevation reason down
R-13 — Glow
Glow may only be used as a focus accent on a maximum of 1-2 important elements
FORBIDDEN as default without purpose: all cards having identical size, icon, padding, and layout
Create visual variation that reflects content hierarchy, and write the hierarchy reason down
Not every feature needs to be presented as a card
R-19 — Animations
Animations must have a clear UX purpose, and the purpose written down
FORBIDDEN as default without purpose: every element using Fade Up + Floating + Scale + Bounce simultaneously
Motion must match the declared MOTION dial (Part 3): a claimed "cinematic" page must actually move; a claimed "static" page must not
Use animation to guide attention, not just to fill the page
R-22 — Illustrations
FORBIDDEN as default without purpose: Undraw, Storyset, or generic 3D blob character illustrations
Illustrations must have a direct connection to the product or content, with the connection written down
If no appropriate and original illustration exists, use real screenshots or no illustration at all
Group 3: Quality Locks (consistency)
These are consistency requirements. They stay as-is, with two adjustments: R-05 now references the RHYTHM dial, and R-31 is upgraded to the keystone rule.
FORBIDDEN: "How It Works" always in 3 steps with round icons and numbers
FORBIDDEN: generic "Trusted By" logo bar directly below the hero
FORBIDDEN: 4-column template footer with Product / Company / Resources / Legal and no variation
FORBIDDEN: every section using the same internal layout pattern (centered title + subtitle + identical card grid); see "Uniform Section Rhythm". Composition variety comes from DESIGN.md, not from a template
Every page must have a structure built around actual content needs
Section order must follow the product's narrative flow, not the AI default order (see Craftsmanship Standard C-3)
Section composition must match the declared RHYTHM dial (Part 3): if RHYTHM is 3 (varied), sections must visibly vary; if RHYTHM is 1 (uniform), uniformity is a deliberate choice, not an accident
R-11 — Border Radius
Use border radius that is consistent with the defined design system
FORBIDDEN: making every element pill-shaped (pill buttons, pill cards, pill inputs, pill badges)
Radius variation is a visual hierarchy tool; use it deliberately
The design must have a strong identity: a specific palette, a typeface chosen for a reason, a unique composition
Every section must have a clear hierarchy
Layout is built around the actual product content needs
Identity comes from deliberate, explained choices, not from adding decoration (see Craftsmanship Standard C-1)
R-21 — Dark Mode
Choose a theme based on brand identity, product type, and target users
Developer tools, terminals, and creative tools have strong, legitimate reasons for a dark default. Use that reason, not "dark looks tech"
If the product has no strong reason for a fixed theme, build a working light/dark toggle. "Give the user a choice" means build the toggle, not defer the work
FORBIDDEN: using this rule (or any rule) as an excuse to skip or defer requested work. If the product should support dark mode, implement it now
A theme toggle you ship must work correctly in BOTH modes. A dark mode that breaks the light mode is a defect (see R-34)
R-29 — Color Palette
REQUIRED: limit the active palette to a maximum of 2-3 core colors + 1 accent color
FORBIDDEN: using 5+ different colors on one page without a clear design system
Neutral colors (white, black, grey) do not count as part of the core palette
Palette consistency is the foundation of a strong visual identity
R-30 — Do Not Clone Popular Products
FORBIDDEN: building a visual that overall mimics another product without being asked
"Make it look like Linear" (unless the user explicitly asks for it)
"Make it look like Vercel" (unless the user explicitly asks for it)
"Make it look like Stripe / Notion / Apple" (unless the user explicitly asks for it)
AI defaults to cloning popular products because those patterns dominate training data
Visual references may be used as inspiration, not as a template to copy
The product must have its own visual identity, not the identity of another product
R-31 — Every Decision Must Have a Reason (Write It Down)
Before finishing the design, write a one-line reason for every major decision:
Why this color?
Why this layout?
Why this typography?
Why this spacing?
Why use cards?
Why use this illustration or icon?
If the reason cannot be written in one line, the decision is not valid and must be revisited. This rule is the keystone of this document: a technique is allowed only when its purpose is articulable. Writing the reason forces intent, and it is what the Purpose-Gate group (Group 2) checks.
Part 3: Liveliness Toolkit
A filter can remove slop, but it cannot add energy. Removing slop leaves a void, and the model fills that void with its most generic output. Liveliness must be added deliberately. This Part is that mechanism: positive requirements, not bans.
Three Dials (required)
Every design must set three dials explicitly, derived from DESIGN.md or the Design Read, and hold them from the first section to the last:
Dial
1 (Calm)
2 (Balanced)
3 (Bold)
What it answers
ENERGY
Linear, GOV.UK
Stripe, Vercel
Awwwards, agency portfolio
How hard does this design say hello?
RHYTHM
Uniform grid, predictable
Consistent with a few breaks
Asymmetric, mixed compositions
How much do sections change from each other?
MOTION
Hover states only
Scroll-reveal, transitions
Parallax, pin, choreography
How much motion, and why?
The anchors (Linear, GOV.UK, Stripe, Vercel, Awwwards) are taste references for judging a value, not things to imitate.
Why three levels and not ten: a model and a reviewer can reliably tell "is this section uniform or varied?" (binary, checkable). They cannot reliably judge "is this a 6 or a 7?" (continuous, uncheckable). Three levels make liveliness enforceable.
Example sets: a designer portfolio sets ENERGY 3, RHYTHM 3, MOTION 2. A public-service site sets ENERGY 1, RHYTHM 1, MOTION 1.
Levers (how the dials become visual decisions)
These are tools for hitting the dial values, not bans:
One focal point per screen: exactly one element that is clearly the most important on every screen; the rest defer to it
Hierarchical contrast: size, weight, and color are differentiated on purpose, not randomly
Whitespace as structure: empty space separates and sets rhythm, not leftover space
One deliberate accent: one color or gesture used sparingly at the key moment. Zero accents is sterile; an accent everywhere is slop
Identity motif: one pattern, gesture, or typographic voice that is specific and repeated, making the design "belong" to the product
Design Read (how the dials are set)
Before generating, declare one line:
Reading this as: <page kind> for <audience>, in a <visual language> style, dial <ENERGY/RHYTHM/MOTION>.
Example: "Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language, dial ENERGY 1 / RHYTHM 2 / MOTION 1."
Direction exists (DESIGN.md or a brief that expresses energy and mood): infer the dials from it and proceed. DESIGN.md may optionally include a line like Dial: ENERGY 2 / RHYTHM 3 / MOTION 1; if present, use it directly.
Direction is ambiguous: ask exactly ONE decisive question, never a question dump. Example: "Should this feel closer to Linear-clean or Awwwards-experimental?" Use the answer to set the dials.
No direction and the user cannot be asked: label the output "draft without direction", set the honest default dials ENERGY 1 / RHYTHM 1 / MOTION 1 (see R-37), and do not present it as a deliverable.
Functional Patterns
"What works" means one of these, depending on context:
Anchor to a real section: href="#pricing" where #pricing exists
Scroll to relevant content for a "Learn more" style link
Open a modal or dialog for a quick action (closable with Escape)
Toggle a state: mobile menu, theme, accordion, tabs
External action: mailto:, a real product URL
Form submit with visible feedback
If none of these applies to an element, the element should not exist.
Delivery Gate (Mandatory)
Run this gate BEFORE delivering. Output its status with your deliverable as a PASS/FAIL report: one line per item, and every PASS backed by concrete evidence (e.g. "R-26 PASS: every button has a real href or onClick; no dead controls").
If any item is FAIL (or any answer is yes), do not deliver: fix it first, then re-run. A report containing a FAIL must never be shipped.
The gate has four blocks: Hard Gate (absolute), Purpose-Gate (technique + written reason), Liveliness (dials + levers), Craftsmanship & Quality Locks (C-1..C-5 plus the consistency locks R-05, R-11, R-15, R-16, R-20, R-21, R-29, R-30, R-31).
Block 1: Hard Gate (absolute)
Before declaring the design done, answer every question below. All answers must be no:
Is there an em dash (—) anywhere in the text, outside the allowed R-02 example? (R-02)
Is there any horizontal overflow, text escaping its container, or broken layout on mobile? (R-03)
Are there any statistics without a real source (10K+ Users, 99.9% Uptime, etc.)? (R-17)
Are there any fictional testimonials (AI avatars, random names or job titles)? (R-18)
Were any visual assets (logo, avatar/profile photo, statistics, testimonials, or navigation structure) created without explicit instructions or confirmation, or without an honest placeholder? (R-23)
Are there navbar links pointing to sections or pages that do not exist? (R-24)
Is there any text with contrast below the WCAG AA standard (4.5:1 for normal text, 3:1 for large text)? (R-25)
Are there any buttons, dropdowns, or forms that do nothing, with no real behavior and no // TODO + visible label? (R-26)
Does the UI lack an empty state, loading state, or error state? (R-27)
Does the FAQ contain generic questions that are not relevant to the product? (R-28)
Can the UI not be navigated by keyboard (Tab, Enter, Escape) or is there no visible focus state? (R-32)
Was any feature added by patching source/CSS with an external script instead of writing it in source? (R-33)
If a theme toggle exists, does one mode (light or dark) break styles, fonts, or layout? (R-34)
Was the app run/built and every interactive element exercised before delivery? (R-35)
Are there any fabricated security, compliance, performance, or customer claims? (R-36)
Was the design built without a style direction, or was it built without direction AND not labeled with honest default dials ENERGY 1 / RHYTHM 1 / MOTION 1?
For each technique, the technique itself is allowed. FAIL if it appears as a default without purpose, or if the reason is not written down:
Do gradients/glows appear as a default with no stated hierarchy or brand purpose? (R-01)
Are there generic icons (sparkle, star, magic, lightning, diamond, robot, orb) or icons irrelevant to their content, with no written relevance? (R-04)
Is there a large monospace font, uppercase label with wide tracking, or a typeface chosen without a written brand-character reason? (R-06)
Is there a background grid, blueprint, or graph paper without a written visual-identity purpose? (R-07)
Are arrows (→ / ↗) placed on almost every button purely as decoration, with no written purpose? (R-08)
Are there capsule badges ("AI Powered", "Beta", "New", "Secure", "Fast") with no real function, or the full capsule + thin border + glow + uppercase combination? (R-09)
Is glassmorphism applied to more than 1-2 elements simultaneously (navbar + card + modal + sidebar)? (R-10)
Is a large shadow applied to every component, with no written elevation reason, making the page feel like it is floating? (R-12)
Is glow applied to cards, buttons, badges, icons, backgrounds, and borders simultaneously? (R-13)
Do all feature cards have identical size, icon, padding, and layout, with no written hierarchy reason? (R-14)
Do all elements use template animations simultaneously (Fade Up + Floating + Scale + Bounce) without a written UX purpose, or does the motion contradict the declared MOTION dial? (R-19)
Are there generic illustrations (Undraw, Storyset, 3D blob) with no written product connection? (R-22)
Block 3: Liveliness (required to be alive, not just clean)
All answers must be yes:
Are the dials set and explicit (ENERGY / RHYTHM / MOTION declared)?
Is the output consistent with the claimed dials? (RHYTHM 3 but uniform sections = FAIL)
Is there at least one clear focal point per screen?
Is whitespace structural (used to separate and set rhythm), not leftover?
Is there one deliberate accent (not zero, not everywhere)?
Is there an identity motif (one specific, repeated pattern, gesture, or typographic voice)?
Was a Design Read declared before generation?
Block 4: Craftsmanship & Quality Locks
All answers must be no:
C-1: Is there any visual or copy decision whose only justification is "it's the AI default"? (Intentionality)
C-2: Does any interactive element do nothing, with no clear label? (Functional Completeness)
C-3: Does any section exist only to fill an AI template, not to serve the product's content? (Content-Driven Composition)
C-4: Does the UI break in any state, theme, breakpoint, or without a mouse? (Resilience)
C-5: Is any testimonial, statistic, or claim fabricated? (Evidence Over Claims)
Does the layout follow an AI template (generic Hero+cards, "How It Works" always 3 steps, "Trusted By" logo bar, 4-column footer with no variation, uniform section rhythm), or does the section rhythm contradict the declared RHYTHM dial? (R-05)
Are all elements (buttons, cards, inputs, badges) made pill-shaped with no radius variation? (R-11)
Are CTAs still generic (Get Started, Learn More, Try Now, Explore, Discover)? (R-15)
Are there any AI marketing buzzwords (AI Powered, Seamless, Revolutionary, Cutting Edge, etc.)? (R-16)
Does the design still feel generic even if the logo and product name are swapped? (R-20)
Was dark mode forced as a default without a branding/user reason, or was a required light/dark toggle deferred with an excuse? (R-21)
Does the color palette exceed 2-3 core colors + 1 accent without a clear design system? (R-29)
Does the overall design look like a clone of another popular product (Linear, Vercel, Stripe, Notion, etc.)? (R-30)
Is there any major visual decision (color, layout, typography, spacing, cards, illustration) whose reason cannot be written in one line? (R-31)
If even one answer is yes (or no in Block 3), do not deliver. Fix it, re-run the gate, and only then ship. Delivery without a clean gate is a failure.
Attribution
This is a clean methodology port of antislop.md from miqdadbadjuber/anti-slop (MIT). No scripts, assets, or dependencies are bundled; only the prose methodology is retained. Complements the bundle's hallmark, taste-skill, baseline-ui, improve-ui, and huashu-design skills.
"draft without direction"
(R-37)
Is there any realistically-styled content that was fabricated (testimonials, features, statistics, ghost links, fictional team) without a real source? (R-38)
