Tailwind

---
name: tailwind
category: tech
user-invocable: false
description: Tailwind CSSを、utility-first（早すぎる抽象化を避ける）という思想で運用し、UI実装の認知負荷を下げながら一貫性と保守性を保つための設計・レビュー・リファクタ判断を整理する。doc/input/rdd.md に「技術スタック Tailwind」または「技術スタック Tailwind CSS」がある場合や、CSS設計/命名/デザインシステム/クラス肥大化の相談で使う。
---

# Tailwind Cognitive Flow Skill

## 公式情報
- [Tailwind CSS](https://tailwindcss.com)
- [Docs](https://tailwindcss.com/docs)

## 発火条件（リポジトリ判定）
- `doc/input/rdd.md` に `技術スタック Tailwind` または `技術スタック Tailwind CSS` がある場合、このSkillを優先適用する。
- 記載がなくても、依頼が Tailwind / utility-first / CSS設計 / クラスの増殖 / コンポーネント化の境界 / デザインシステム に該当するなら適用する。

## この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の揺れが増える
- “クラスが多い＝悪”と決めつけて、無理に抽象化して読みづらくする
- 共通化の単位が「見た目」だけになり、責務が曖昧な巨大コンポーネントが生まれる