mcpField
A
anti-ai-slop-ui

anti-ai-slop-ui

github.com/rwcodDesign & UI2196 installsUpdated 19w ago
Repository

About anti-ai-slop-ui

A skill that guides agents to plan and review product-specific UI instead of relying on generic AI-generated patterns. It provides a staged design process, reference material, checklists, scoring rubrics, and a lint script.

Key features

  1. 01Classify UI tasks and infer context
  2. 02Choose visual direction and layout
  3. 03Define design tokens before coding
  4. 04Review accessibility and quality
  5. 05Score distinctiveness and generic patterns
  6. 06Lint UI code for common tells

Use cases

  1. 01Plan a product-specific landing page
  2. 02Review a dashboard for generic patterns
  3. 03Refactor a shadcn/Tailwind interface

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/rwcod/anti-ai-slop-ui --skill anti-ai-slop-ui

After installing, type/anti-ai-slop-uiin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

.gitignore
LICENSE
README.md
checklists/
accessibility_basics.md
ui_review_checklist.md
dashboard_checklist.md
landing_page_checklist.md
examples/
bad_to_good_dashboard.md
bad_to_good_landing.md
native_macos_utility_example.md
prompt_examples.md
references/
motion_rules.md
anti_slop_patterns.md
typography_guidance.md
layout_patterns.md
visual_directions.md
rubrics/
implementation_readiness_score.md
distinctiveness_score.md
ai_slop_score.md
scripts/
install_skill.py
ui_lint.py
templates/
design_brief_template.md
ui_generation_output.md
ui_review_output.md
design_tokens_template.json

Details

From the project README

anti-ai-slop-ui

Prevent AI agents from producing generic, instantly recognizable, vibe-coded UI.

Do not default to the average AI SaaS interface. Produce product-specific design by defining visual direction, design tokens, layout strategy, motion rules, and an anti-slop quality gate before writing UI code.

Core principle

Do not start with components. Start with design intent.

When to use

  • landing pages, SaaS UI, dashboards, onboarding flows
  • app screens (desktop/mobile)
  • frontend components, Figma/mockups
  • UI redesigns and UI quality reviews
  • shadcn/Tailwind UI refactors

When not to use

  • pure backend, database-only, DevOps-only work
  • data processing, CLI-only scripts, text-only writing
  • unless the task includes visible UI

Mandatory process

Follow this order. Do not skip steps.

1. Classify the UI task

Identify one primary type:

  • landing page / product marketing page
  • app dashboard / admin / control panel
  • onboarding flow
  • mobile or desktop app screen
  • component library work
  • redesign or review
  • Figma/mockup generation
  • implementation or refactor

Use the matching checklist when reviewing:

  • checklists/landing_page_checklist.md
  • checklists/dashboard_checklist.md
  • checklists/ui_review_checklist.md
2. Infer product context

Determine:

  • product type, target user, primary user action
  • platform, information density, trust requirement
  • emotional tone, brand maturity, business goal
  • accessibility expectations

If information is missing, state a brief assumption. Do not block unless the gap is essential.

Use templates/design_brief_template.md for generation tasks.

3. Choose a concrete visual direction

Pick one direction with constraints. Do not use vague labels like "modern", "clean", or "sleek" without specifics.

Read references/visual_directions.md and choose one, for example:

  • Native macOS Utility
  • Developer Tool / CLI Companion
  • Enterprise Control Plane
  • Security Operations Console
  • Research Archive
  • Premium Wellness Companion
  • Crypto Intelligence Terminal
  • Consumer Creator Tool
  • Financial Dashboard
  • Minimal Editorial Product
  • Playful Consumer App

See references/visual_directions.md for full constraints per direction.

4. Define design tokens before UI code

Before implementation, define:

  • palette, typography, spacing scale
  • radius rules, shadow/elevation rules
  • icon style, motion rules
  • layout rhythm, component density

Use templates/design_tokens_template.json.

Read references/typography_guidance.md and references/motion_rules.md.

5. Select a layout strategy

Do not default to:

centered hero -> subtitle -> two CTAs -> three cards -> bento -> FAQ -> CTA

Choose a product-specific layout from references/layout_patterns.md, for example:

  • asymmetric product hero
  • command center
  • editorial split
  • workflow timeline
  • native settings window
  • evidence ledger
  • dense dashboard
  • one big object
  • problem / evidence / outcome
  • product storyboard
6. Avoid common AI/vibe-coded defaults

These are dangerous defaults that require product-specific justification. Do not use them unless the user asks or there is a strong product reason.

Read references/anti_slop_patterns.md for tells and alternatives.

Discourage by default:

  • default shadcn/Tailwind visual language
  • purple/indigo AI palette, purple-to-blue gradients, gradient hero text
  • centered hero + three cards + CTA
  • emoji icons as UI elements
  • dark neon glow without purpose
  • glassmorphism everywhere
  • aurora/blob/blur decoration without purpose
  • rounded corners on everything
  • Inter/Geist as unexamined defaults
  • hover animation on every card
  • scroll reveal everywhere
  • generic SaaS section rhythm
  • bento grid as default decoration
  • empty whitespace used to fake premium design
  • visually identical cards with equal weight
7. Generate or review UI

Generation: customize components deeply, avoid raw demo components, make hierarchy obvious, use coherent icons, define empty/loading/error states, keep motion functional, preserve accessibility basics, test responsive behavior.

Review: identify generic tells, explain why, rank fixes by impact, propose revised direction.

Use checklists/accessibility_basics.md for all UI work.

Study examples/ for contrast cases:

  • examples/bad_to_good_landing.md
  • examples/bad_to_good_dashboard.md
  • examples/native_macos_utility_example.md
8. Run AI Slop Score and Distinctiveness Score

Score before final delivery:

  • rubrics/ai_slop_score.md
  • rubrics/distinctiveness_score.md
  • rubrics/implementation_readiness_score.md (for generation briefs)

Quality-gate questions:

  • Does this look like a default shadcn demo?
  • Is the main accent purple/indigo without a product reason?
  • Is there a gradient hero headline?
  • Is the page basically hero + three cards + CTA?
  • Are emojis used as icons?
  • Are all cards/buttons/modals heavily rounded?
  • Is there glow, aurora, blob, blur, or glass decoration without purpose?
  • Is Inter/Geist used only because it was the default?
  • Are hover/scroll animations excessive?
  • Would a frontend/design subreddit say "this screams AI"?
9. Revise if the UI looks generic
  • AI Slop Score 0-4: proceed with minor notes
  • AI Slop Score 5-6: revise highest-impact areas
  • AI Slop Score 7+: do not ship; redesign visual direction and layout
  • Distinctiveness Score below 7: propose at least three specific improvements
10. Output implementation-ready notes/code

Use the correct output template:

  • generation: templates/ui_generation_output.md
  • review: templates/ui_review_output.md

Required output formats

UI generation
  1. Design direction
  2. Token decisions
  3. Layout strategy
  4. Implementation/code
  5. Anti-slop check (scores + risks)
  6. Remaining trade-offs
UI review
  1. Direct diagnosis
  2. Generic tells found
  3. Why they happen
  4. Priority fixes
  5. Revised design direction
  6. AI Slop Score
  7. Distinctiveness Score
  8. Concrete implementation steps

Resource map

RoleFile
Visual tells + alternativesreferences/anti_slop_patterns.md
Direction libraryreferences/visual_directions.md
Non-default layoutsreferences/layout_patterns.md
Font/type decisionsreferences/typography_guidance.md
Functional motionreferences/motion_rules.md
Pre-generation brieftemplates/design_brief_template.md
Token structuretemplates/design_tokens_template.json
Generation output shapetemplates/ui_generation_output.md
Review output shapetemplates/ui_review_output.md
Slop scoringrubrics/ai_slop_score.md
Distinctiveness scoringrubrics/distinctiveness_score.md
Readiness scoringrubrics/implementation_readiness_score.md
General review checklistchecklists/ui_review_checklist.md
Landing page checklistchecklists/landing_page_checklist.md
Dashboard checklistchecklists/dashboard_checklist.md
Accessibility basicschecklists/accessibility_basics.md
Landing contrast exampleexamples/bad_to_good_landing.md
Dashboard contrast exampleexamples/bad_to_good_dashboard.md
Native macOS utility exampleexamples/native_macos_utility_example.md
Reusable task promptsexamples/prompt_examples.md
Install to agentsscripts/install_skill.py
UI slop heuristic lintscripts/ui_lint.py

Utility scripts

Run these when helpful. They do not replace the design process above.

scripts/install_skill.py

For users who cloned the repo. Symlinks (default) or copies this skill into agent skill directories.

python scripts/install_skill.py
python scripts/install_skill.py --status

Public install alternative: npx skills add rwcod/anti-ai-slop-ui

scripts/ui_lint.py

After implementing or reviewing UI code, scan for measurable slop tells:

python scripts/ui_lint.py ./src
python scripts/ui_lint.py path/to/Component.tsx

Use output as input to AI Slop Score — not as the final verdict. False positives are expected.

Strong default instruction

Before implementing UI, create a short design direction and design token plan.

Use a distinct, product-specific visual language. Prioritize hierarchy, restraint, asymmetry where useful, platform-native conventions where relevant, and functional motion only.

First define the visual system. Then implement the UI.

Comments

Markdown supported