| name | tailwind |
| category | tech |
| description | Tailwind CSSを、utility-first（早すぎる抽象化を避ける）という思想で運用し、UI実装の認知負荷を下げながら一貫性と保守性を保つための設計・レビュー・リファクタ判断を整理する。doc/rdd.md に「技術スタック Tailwind」または「技術スタック Tailwind CSS」がある場合や、CSS設計/命名/デザインシステム/クラス肥大化の相談で使う。 |
Tailwind Cognitive Flow Skill
公式情報
発火条件（リポジトリ判定）
doc/rdd.mdに技術スタック Tailwindまたは技術スタック Tailwind CSSがある場合、このSkillを優先適用する。- 記載がなくても、依頼が Tailwind / utility-first / CSS設計 / クラスの増殖 / コンポーネント化の境界 / デザインシステム に該当するなら適用する。
このSkillの基本方針（整理軸）
- 基本方針: UIを組み立てるときは、命名や抽象化で思考を止めない。まずutilityで形にし、抽象化は必要になってから行う。
- 設計観: 「再利用したい形」が見えた時点で、コンポーネント/抽象（React/Vue/Svelte等）へ移す。
- 一貫性: デザインの揺れは “値” で吸収する。tokens（色/余白/フォント）とコンポーネント境界で統制する。
- 保守性: クラス肥大は悪ではないが、「責務が曖昧な塊」になるのは悪。UIの責務単位で分割する。
思想（判断ルール）
- 早すぎる抽象化（命名・共通クラス化）を避ける。まず具体で組み立てる。
- “同じ見た目が3回以上”出たら抽象化を検討する（コンポーネント化/共通化）。
- tokens を先に決める（色/余白/タイポ）。揺れはtokensで止め、場当たり値を増やさない。
- クラスを読む負担が増えたら、構造（コンポーネント）で解決する。CSSの抽象で解決しない。
- UIの意図（レイアウト/間隔/強調）を、クラスの並びとして可視化する。
進め方（最初に確認する問い）
- これはデザインシステムがある？（既存トークン/規約）
- UIはどの程度再利用する？（ページ固有 or 共通コンポーネント中心）
- クラスの増殖が問題？それとも見た目の揺れが問題？
- 「実装速度」と「一貫性」、どっちを優先する？
出力フォーマット（必ずこの順）
- 推奨方針（1〜3行）
- 理由（認知負荷 / 一貫性 / 保守性）
- 設計案（tokens / コンポーネント境界 / クラス整理のルール）
- チェックリスト
- 落とし穴
- 次アクション（小さく試す順）
チェックリスト
速度と認知負荷
- 命名のために手が止まっていないか（utilityでまず形にしたか）
- “局所最適の共通化”で読みづらくしていないか
一貫性（tokens）
- 色/余白/文字サイズがtokens（規約）に寄っているか
- 任意のpx値が増えすぎていないか（揺れの原因）
抽象化（コンポーネント境界）
- 同じUIが繰り返される箇所はコンポーネント化できているか
- 逆に、再利用しないのにコンポーネント化して複雑化していないか
- 1コンポーネントに責務（レイアウト/状態/見た目）が詰まりすぎていないか
クラスの健全性
- “見た目の意図”がクラスから読み取れるか（レイアウト→間隔→装飾の順）
- 並び順ルールがあるか（例: layout → spacing → typography → color → effect）
よくある落とし穴
- すぐに命名・共通CSSを作り始めて、Tailwindの旨味（思考の流れ）が消える
- tokens を決めずに任意値だらけになり、UIの揺れが増える
- “クラスが多い＝悪”と決めつけて、無理に抽象化して読みづらくする
- 共通化の単位が「見た目」だけになり、責務が曖昧な巨大コンポーネントが生まれる