tailwind

name	tailwind
user-invocable	false
description	Tailwind CSSをutility-first（早すぎる抽象化を避ける）思想で運用し、UI実装の認知負荷を下げながら一貫性と保守性を保つための設計・レビュー・リファクタ判断を整理する。Tailwind CSS、utility-first、CSS設計、クラス肥大化、デザイントークン、コンポーネント化の境界、レスポンシブ設計、ダークモード、tailwind.config、@applyの使い方に関する相談で必ず使うこと。ユーザーが「クラスが長すぎる」「CSS設計を統一したい」「デザインシステムを作りたい」と言った場合、Tailwindが技術スタックに含まれていれば適用する。

Tailwind Cognitive Flow Skill

公式情報

• Tailwind CSS
• Docs

このSkillの基本方針

• 基本方針: UIを組み立てるときは、命名や抽象化で思考を止めない。まずutilityで形にし、抽象化は必要になってから行う。
• 設計観: 「再利用したい形」が見えた時点で、コンポーネント/抽象（React/Vue/Svelte等）へ移す。
• 一貫性: デザインの揺れは “値” で吸収する。tokens（色/余白/フォント）とコンポーネント境界で統制する。
• 保守性: クラス肥大は悪ではないが、「責務が曖昧な塊」になるのは悪。UIの責務単位で分割する。

思想（判断ルール）

1. 早すぎる抽象化（命名・共通クラス化）を避ける。まず具体で組み立てる。
2. “同じ見た目が3回以上”出たら抽象化を検討する（コンポーネント化/共通化）。
3. tokens を先に決める（色/余白/タイポ）。揺れはtokensで止め、場当たり値を増やさない。
4. クラスを読む負担が増えたら、構造（コンポーネント）で解決する。CSSの抽象で解決しない。
5. UIの意図（レイアウト/間隔/強調）を、クラスの並びとして可視化する。

進め方（最初に確認する問い）

• これはデザインシステムがある？（既存トークン/規約）
• UIはどの程度再利用する？（ページ固有 or 共通コンポーネント中心）
• クラスの増殖が問題？それとも見た目の揺れが問題？
• 「実装速度」と「一貫性」、どっちを優先する？

出力フォーマット（必ずこの順）

1. 推奨方針（1〜3行）
2. 理由（認知負荷 / 一貫性 / 保守性）
3. 設計案（tokens / コンポーネント境界 / クラス整理のルール）
4. チェックリスト
5. 落とし穴
6. 次アクション（小さく試す順）

チェックリスト

速度と認知負荷

• 命名のために手が止まっていないか（utilityでまず形にしたか）
• “局所最適の共通化”で読みづらくしていないか

一貫性（tokens）

• 色/余白/文字サイズがtokens（規約）に寄っているか
• 任意のpx値が増えすぎていないか（揺れの原因）

抽象化（コンポーネント境界）

• 同じUIが繰り返される箇所はコンポーネント化できているか
• 逆に、再利用しないのにコンポーネント化して複雑化していないか
• 1コンポーネントに責務（レイアウト/状態/見た目）が詰まりすぎていないか

クラスの健全性

• “見た目の意図”がクラスから読み取れるか（レイアウト→間隔→装飾の順）
• 並び順ルールがあるか（例: layout → spacing → typography → color → effect）

よくある落とし穴

• すぐに命名・共通CSSを作り始めて、Tailwindの旨味（思考の流れ）が消える
• tokens を決めずに任意値だらけになり、UIの揺れが増える
• “クラスが多い＝悪”と決めつけて、無理に抽象化して読みづらくする
• 共通化の単位が「見た目」だけになり、責務が曖昧な巨大コンポーネントが生まれる