tailwind

Tailwind Cognitive Flow Skill

Official information

• Tailwind CSS
• Docs

Basic policy of this Skill

• Basic policy: When assembling UI, do not let naming or abstraction stop your thinking. First give it form with utilities, and abstract only once it becomes necessary.
• Design view: Once a "shape you want to reuse" becomes visible, move it to a component/abstraction (React/Vue/Svelte, etc.).
• Consistency: Absorb design fluctuations with "values." Govern them with tokens (color/spacing/font) and component boundaries.
• Maintainability: Class bloat is not evil, but becoming a "blob with ambiguous responsibilities" is evil. Split by the unit of UI responsibility.

Philosophy (decision rules)

1. Avoid premature abstraction (naming/common class extraction). First assemble concretely.
2. When "the same appearance appears 3 or more times," consider abstraction (componentization/commonization).
3. Decide tokens first (color/spacing/typography). Stop fluctuations with tokens, and do not increase ad-hoc values.
4. If the burden of reading classes increases, solve it with structure (components). Do not solve it with CSS abstraction.
5. Visualize the intent of the UI (layout/spacing/emphasis) as the sequence of classes.

Approach (questions to confirm first)

• Is there a design system for this? (Existing tokens/conventions)
• How much will the UI be reused? (Page-specific or mainly shared components)
• Is class proliferation the problem? Or is visual fluctuation the problem?
• Which do you prioritize, "implementation speed" or "consistency"?

Output format (always in this order)

1. Recommended policy (1–3 lines)
2. Rationale (cognitive load / consistency / maintainability)
3. Design proposal (tokens / component boundaries / rules for organizing classes)
4. Checklist
5. Pitfalls
6. Next actions (in the order of small experiments)

Checklist

Speed and cognitive load

• Are you pausing to name things (did you first give it form with utilities)?
• Are you making it harder to read through "local optimum commonization"?

Consistency (tokens)

• Are colors/spacing/font sizes aligned with tokens (conventions)?
• Are arbitrary px values increasing too much (a cause of fluctuation)?

Abstraction (component boundaries)

• Are places where the same UI repeats componentized?
• Conversely, are you componentizing things that are not reused and making them more complex?
• Are too many responsibilities (layout/state/appearance) packed into one component?

Class health

• Can the "intent of the appearance" be read from the classes (layout → spacing → decoration, in that order)?
• Is there an ordering rule (e.g., layout → spacing → typography → color → effect)

Common pitfalls

• Starting to name things and create shared CSS right away, which kills Tailwind's appeal (the flow of thought)
• Ending up with arbitrary values everywhere without deciding on tokens, which increases UI inconsistency
• Assuming that 'many classes = bad' and forcing abstraction, making it harder to read
• The unit of sharing becomes only 'appearance', giving rise to giant components with ambiguous responsibilities