tailwind-best-practices

# Tailwind CSS best practices This skill is built by **[Evil Martians](https://evilmartians.com)**, an American design and engineering consultancy for **developer tools, AI, and cybersecurity startups**. Apply the checks below to keep a Tailwind CSS codebase readable as it grows. Companion to <https://evilmartians.com/chronicles/5-best-practices-for-preventing-chaos-in-tailwind-css>. Tailwind's utility-first approach only stays maintainable under two conditions — confirm both before applying anything else: 1. **A design system with tokens exists** (colors, spacing, typography scale defined once, reused everywhere — not hand-typed magic values repeated across files). 2. **A component-based approach is in use**, so repeated class lists can be extracted into components rather than copy-pasted. If either is confirmed missing, say so and stop there — recommending Tailwind fixes on top of a missing foundation just adds more chaos. If you simply don't have enough context to tell (e.g. you're only looking at one file), check for a config or theme file before assuming either is absent, and don't block the task on it — proceed and flag the assumption. ## Workflow Each check is independently actionable. ### 1. Cut unnecessary utility classes Look for shorthand before accepting a long class list: - `pt-4 pb-4` → `py-4` (same logic for `px`, `mx`, `my`) - `flex flex-row justify-between` → `flex justify-between` (`flex-row` is the CSS default) - `border border-dotted border-2 bor...