baseline-ui

name	baseline-ui
description	Validates animation durations, enforces typography scale, checks component accessibility, and prevents layout anti-patterns in Tailwind CSS projects. Use when building UI components, reviewing CSS utilities, styling React views, or enforcing design consistency.
type	skill
created	2026-02-27T00:00:00.000Z
domain	software-development
category	frontend
risk	unknown
source	community
tags	["skill","software-development","frontend","baseline"]

Baseline UI

Enforces an opinionated UI baseline to prevent AI-generated interface slop.

When to Use

• You are building or reviewing Tailwind-based UI and want a strict baseline for accessibility, motion, typography, and layout.
• The task is to prevent generic or sloppy AI-generated interface decisions before they spread through the codebase.
• You need concrete UI constraints to apply to a file review or an ongoing frontend implementation.

How to use

• /baseline-ui Apply these constraints to any UI work in this conversation.

• /baseline-ui <file> Review the file against all constraints below and output:

  • violations (quote the exact line/snippet)
  • why it matters (1 short sentence)
  • a concrete fix (code-level suggestion)

Stack

• MUST use Tailwind CSS defaults unless custom values already exist or are explicitly requested
• MUST use motion/react (formerly framer-motion) when JavaScript animation is required
• SHOULD use tw-animate-css for entrance and micro-animations in Tailwind CSS
• MUST use cn utility (clsx + tailwind-merge) for class logic

Components

• MUST use accessible component primitives for anything with keyboard or focus behavior (Base UI, React Aria, Radix)
• MUST use the project’s existing component primitives first
• NEVER mix primitive systems within the same interaction surface
• SHOULD prefer Base UI for new primitives if compatible with the stack
• MUST add an aria-label to icon-only buttons
• NEVER rebuild keyboard or focus behavior by hand unless explicitly requested

Interaction

• MUST use an AlertDialog for destructive or irreversible actions
• SHOULD use structural skeletons for loading states
• NEVER use h-screen, use h-dvh
• MUST respect safe-area-inset for fixed elements
• MUST show errors next to where the action happens
• NEVER block paste in input or elements