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.

antislop-ui

antislop-copywriting

SKILL.md

AGENTS.md

CLAUDE.md

GEMINI.md

If the user can use a terminal, the packaged install is better: run

npx antislop-ai

(interactive picker) or

npx skills add miqdadbadjuber/anti-slop

, then skip this section. The steps below are the manual fallback for chat-only setups.

1. Declare the setup before doing anything. Tell the user you will (a) download the skill(s) they choose into

   skills/<name>/

   subfolders next to this file, and (b) append an antislop pointer block at the end of the project's entry file. Get approval. Never modify the entry file silently.
2. Ask which skills to install (multi-select, in the user's chat language). List only the skills that exist in this version of antislop:
   • 1. All (recommended): install every available skill. Choose this when the work spans UI, copy, people, or mobile layout.
   • 2.

     antislop-ui

     (UI / visual): pick this for building or editing a website, web app, or interface: color, layout, components, decoration, motion.
   • 3.

     antislop-copywriting

     (copy & text): pick this for writing or editing copy: headlines, CTAs, value propositions, tone, landing-page text, product prose.
   • 4.

     antislop-human

     (people): pick this for making sure a UI works for people with different eyes, hands, and setups: contrast, keyboard, focus, states.
   • 5.

     antislop-layoutmobile

     (mobile / responsive): pick this for layouts that have to hold up on a phone: breakpoints, scale, grids, overflow, tap targets.
   • New skills appear here as they ship; never offer a skill that does not exist in this version.
   If the user declines or says "core only", stop here and use this file alone as the filter. Do not install anything.
3. Resolve direction (only if a UI skill was selected). Check for

   DESIGN.md

   or explicit brand/style direction. If none exists, be honest that antislop is a filter, not a beautifier: without direction the output tends toward monotonous. Recommend having a

   DESIGN.md

   , then offer these paths:
   • 1. The user supplies direction (recommended). They write their own

     DESIGN.md

     , or answer a few direction questions (identity, personality, palette, typography, mood) and the agent transcribes their answers into

     DESIGN.md

     . The user is the author; the agent only formats. Never invent example content for

     DESIGN.md

     .
   • 2. The agent supplies direction, with an honest warning. The agent writes the direction itself, stating explicitly that agent-generated style tends toward default AI taste, which is the slop antislop filters, so the result is likely monotonous. If chosen, still ask a minimal brief (product, audience, mood) before building.
   • 3. The user skips direction for now. Proceed without a

     DESIGN.md

     . Any UI built this way must be labeled "draft without direction" with dials ENERGY 1 / RHYTHM 1 / MOTION 1 (R-37), and is not a shippable deliverable.
4. No download needed. The skill folders are already installed next to this core: the picker (

   npx antislop-ai

   ) and the skills directory (

   npx skills add miqdadbadjuber/anti-slop

   ) copy them into place. To add or remove a skill later, run

   npx antislop-ai

   again.
5. Append the pointer block at the END of the project's entry file (the file the running tool reads at session start:

   CLAUDE.md

   for Claude Code,

   AGENTS.md

   for Codex,

   GEMINI.md

   for Gemini CLI, and so on). If that file does not exist, create it. Never modify existing content:
   md

   <!-- antislop: auto-managed block, do not edit -->
   ## antislop
   For UI, copy, people, or mobile layout work, read `antislop.md` (core) and then the skill for the task:
   - UI / visual: `skills/antislop-ui/SKILL.md`
   - Copy & text: `skills/antislop-copywriting/SKILL.md`
   - People: `skills/antislop-human/SKILL.md`
   - Mobile / responsive: `skills/antislop-layoutmobile/SKILL.md`
   Before starting, ask the user when antislop applies: during the work, or after it is done.

   If an older antislop block exists (even without the marker), replace just that block instead of appending a duplicate.
6. Ask the usage-mode question (see "Two Usage Modes"), then proceed with the work.

• The entry file is read at the start of a session, so a newly written pointer takes effect from the next session.
• The wizard needs file-write access for step 5 (the pointer block); the user approves once. Skills are already installed in this packaged form.
• The pointer block is the source of truth for which skills are installed. To add or remove a skill later, update the block to match (add or remove the file and its line).

When do you want to use antislop?

1. DURING the project, while working (planning & execution). I will apply the rules while I write, so AI slop does not appear from the start.
2. 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.

antislop.md

• 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:
  1. Holds every visual decision to a purpose test: what does this technique serve? Write the reason down.
  2. Holds the result to a liveliness bar: the output must be alive and specific, not just "clean". See Part 3.

antislop.md

• 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.

If the logo and product name were swapped out, would this design still feel unique and have its own character?

1. Every technique passes the purpose test (see the Purpose-Gate group in Part 2).
2. It has its own identity and character (see Part 3: Liveliness Toolkit).
3. It actually works (see The Craftsmanship Standard).

• FORBIDDEN: em dash character (

  —

  ) in any text
• Use comma (

  ,

  ), period (

  .

  ), colon (

  :

  ), or parentheses

  ()

  instead
• Text must feel natural and human
• Carve-out: documentation of this rule is exempt: the numbered section headings in this file (

  R-XX — Title

  rules and

  C-1

  to

  C-5

  principles), the em dash example in Part 1, the rule's own definition, any Delivery Gate item that quotes it, and the

  Em Dashes

  section in the copywriting skill (

  skills/antislop-copywriting/SKILL.md

  ). These are documentation structure, not UI text.

• 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.

• FORBIDDEN: numbers and statistics without a real source
• If real data is not available, display no numbers at all
• Empty is better than deceptive

• 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

• 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

• 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

• 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

• 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

// TODO

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• Glow may only be used as a focus accent on a maximum of 1-2 important elements
• Dose cap: FORBIDDEN on card + button + badge + icon + background + border simultaneously

• 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

• 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

• 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

• FORBIDDEN: AI template layouts (Hero + 3 cards, Hero + 6 features, Hero + fake stats, etc.)
• 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

• 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

• FORBIDDEN: "Get Started", "Learn More", "Try Now", "Explore", "Discover" as default CTAs
• CTAs must be specific to the product context and the intended action
• Better examples: "Start Your Free Trial", "Watch Live Demo", "Create Free Account"

• FORBIDDEN: "AI Powered", "Next Generation", "Revolutionary", "Seamless", "Cutting Edge", "Intelligent", "Ultimate", "Powerful", "Effortless"
• Use specific language that explains real benefits
• Show evidence, not claims

• 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)

• 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)

• 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

• 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

• Why this color?
• Why this layout?
• Why this typography?
• Why this spacing?
• Why use cards?
• Why use this illustration or icon?

• 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

Reading this as:

<page kind>

for

<audience>

, in a

<visual language>

style, dial

<ENERGY/RHYTHM/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.
2. 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.
3. 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.

• 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

• Is there an em dash (

  —

  ) anywhere in the text, outside the R-02 carve-out? (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, and 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 delivered without being run or built, or with any interactive element left unexercised? (R-35)
• Are there any fabricated security, compliance, performance, or customer claims? (R-36)
• Was the design built without direction and not labeled "draft without direction" with honest default dials ENERGY 1 / RHYTHM 1 / MOTION 1? (R-37)
• Is there any realistically-styled content that was fabricated (testimonials, features, statistics, ghost links, fictional team) without a real source? (R-38)

• 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)

• 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?

• 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)