Tailwind CSS

Use project color tokens only when the intent is clear.
Report a color only when all of these are true:

1. The class uses a raw palette/arbitrary color.
2. The UI intent is obvious from nearby code.
3. A project token is the clear replacement.

Use semantic tokens for semantic intent: positive-*, negative-*, warning-*, and info-*. Use brand/product tokens such as primary-* when the element is clearly brand or primary UI. Do not invent a token replacement for neutral styling or an arbitrary hex value when the intent is not obvious.

{{-- Wrong: error intent is obvious --}}
<div class="border border-red-100 bg-red-50 text-red-700">Error</div>

{{-- Correct --}}
<div class="border border-negative-100 bg-negative-50 text-negative-700">Error</div>

Do not use dark: variant classes.
Dark mode is not in use. Remove any dark: prefixed classes found in existing code.

{{-- Wrong --}}
<div class="bg-white dark:bg-gray-900">

{{-- Correct --}}
<div class="bg-white">

Raw <button> and <a> elements must have a hover: state. Other elements do not need one, even when a click handler makes them interactive: a clickable div, span, td, or th only needs cursor-pointer, and controls such as sliders communicate through their own visual state.
The hover: utility may live on the element itself or on any element inside it. A link whose icon or image declares the hover state already gives the user feedback.
Design-system interactive components such as <x-button> and <x-link> own their hover styles internally, so the Blade invocation does not need a hover: utility.
This rule does not apply to mail templates, where :hover is unreliable across email clients, or to third-party templates published under resources/views/vendor/, which follow their own package styling.

{{-- Wrong --}}
<button class="bg-primary text-white px-4 py-2">Guardar</button>

{{-- Correct --}}
<button class="bg-primary hover:bg-primary-dark text-white px-4 py-2">Guardar</button>
<x-button primary :label="__('Save')" />

Only non-semantic clickable elements need cursor-pointer.
Buttons, links, labels, native controls, and design-system interactive components do not need an explicit cursor-pointer. Add cursor-pointer when a non-semantic element such as div, span, td, or th is made clickable with wire:click, @click, x-on:click, or equivalent.
Do not put cursor-pointer on elements that are not interactive.

{{-- Wrong --}}
<div wire:click="save" class="bg-primary text-white">Guardar</div>
<div class="text-gray-500 cursor-pointer">Texto informativo</div>

{{-- Correct --}}
<button wire:click="save" class="bg-primary text-white">Guardar</button>
<div wire:click="save" class="bg-primary text-white cursor-pointer">Guardar</div>

Remove wrapper divs that have no layout, styling, behavior, or grouping purpose.
A wrapper is valid when it provides spacing, padding, border, overflow, positioning, flex/grid layout, Alpine/Livewire behavior, conditional rendering, semantic grouping, or wraps multiple meaningful children.
In Livewire views, the root wrapper required to keep multiple sibling elements under one root is valid even if it has no classes. Do not report the first/root div when it wraps several meaningful child elements. Report it only when it is a redundant wrapper around a single meaningful child and removing it would still leave one valid root element.
Pass spacing/layout classes directly to a component when the wrapper exists only to style that component.

{{-- Wrong --}}
<div>
    <div>
        <span>Contenido</span>
    </div>
</div>

{{-- Correct --}}
<span>Contenido</span>

{{-- Wrong --}}
<div class="mb-10">
    <x-card>...</x-card>
</div>

{{-- Correct --}}
<x-card class="mb-10">...</x-card>

When an x-dropdown component is present:
Use position instead of align. The align attribute no longer exists on x-dropdown. Use:

• position="bottom" — opens downward, centered (replaces align="center")
• position="top" — opens upward, centered

Set width="xl" on x-dropdown unless there is a specific reason to use a different size.

{{-- Wrong --}}
<x-dropdown align="center">

{{-- Correct --}}
<x-dropdown position="bottom" width="xl">

When an x-modal component is present:
Add w-full to the x-card inside an existing x-modal.
WireUI's modal wrapper uses a flex container. Without w-full, the card shrinks to its content width instead of filling the modal.

{{-- Wrong --}}
<x-modal wire:model="myModal">
    <x-card title="Título" class="z-10">

{{-- Correct --}}
<x-modal wire:model="myModal">
    <x-card title="Título" class="z-10 w-full">

Do not repeat the same utility class on the same element.
If the same class appears twice, remove the duplicate. If you see conflicting classes (e.g., text-sm text-lg), resolve the conflict — do not leave both.

Use Tailwind utilities instead of direct CSS for static visual styling.
Do not add static visual styling with direct CSS when Tailwind can express the same result. This applies whether the CSS is written in a style="" attribute, a <style> block, a CSS file, an imported stylesheet, or a custom class whose only purpose is static visual styling such as spacing, width, height, color, typography, borders, shadows, text decoration, or layout.
Report these findings as direct CSS styling and recommend replacing the CSS with Tailwind utilities. Do not turn the finding into a color-token recommendation.
Direct CSS is allowed when the value is genuinely dynamic at runtime, browser-specific, generated by a third-party integration, required by a vendor, defines reusable project infrastructure that Tailwind cannot express safely, or cannot be represented with Tailwind utilities. Examples include Alpine-bound progress widths, CSS variables populated from runtime data, vendor-required attributes, third-party widget styles, or chart/library container sizing that cannot be moved to Tailwind utilities.
Specifically, these are not findings:

• A style whose value is an expression, such as :style / x-bind:style bound to Alpine, or a style attribute interpolated by Blade.
• style="display: none" paired with x-show or x-cloak, which hides the element until Alpine boots and takes over the display. That is behaviour, not static styling.
• Properties Tailwind has no utility for, such as font-variation-settings on a variable icon font.
• Mail templates, where inline CSS is required, and templates published under resources/views/vendor/, which carry the styling their own package ships.

A fixed container size is a finding, because Tailwind expresses it directly: style="height: 24rem" is h-96.
When direct CSS is necessary, keep it as narrow as possible and do not mix unrelated static styling into it.

Main layout containers must not overflow mobile screens.
Report a responsive width issue only when a fixed width controls a main container, card, form, table, modal, or content column and can overflow on small screens. Suggest the concrete responsive replacement, usually w-full max-w-*.
Fixed or arbitrary sizes are fine for small bounded UI pieces such as icons, avatars, badges, handles, controls, and narrow table/action columns.

{{-- Wrong --}}
<div class="w-[400px] rounded bg-white">

{{-- Correct --}}
<div class="w-full max-w-[400px] rounded bg-white">

A grid of more than two columns starts with fewer columns on small screens.
grid-cols-3 or any higher column count, written without a breakpoint, keeps every column on a phone and squeezes each one into a third of the screen or less: text wraps a word per line, controls overlap, and cards become slivers. Start from one or two columns and add the rest at a breakpoint.
This is a warning, because some grids are meant to stay wide. It is not reported when the column count already changes at a breakpoint or container query, when the children change their col-span-* at a breakpoint, or when the grid is capped at a narrow width or sized to its content (such as max-w-xs, max-w-md, w-fit or inline-grid) — digit boxes, swatches and other small fixed cells.

{{-- Wrong --}}
<div class="grid grid-cols-4 gap-4">

{{-- Correct --}}
<div class="grid grid-cols-1 gap-4 sm:grid-cols-2 lg:grid-cols-4">