tailwind
Installation
SKILL.md
Tailwind Cognitive Flow Skill
公式情報
このSkillの基本方針
- 基本方針: UIを組み立てるときは、命名や抽象化で思考を止めない。まずutilityで形にし、抽象化は必要になってから行う。
- 設計観: 「再利用したい形」が見えた時点で、コンポーネント/抽象(React/Vue/Svelte等)へ移す。
- 一貫性: デザインの揺れは “値” で吸収する。tokens(色/余白/フォント)とコンポーネント境界で統制する。
- 保守性: クラス肥大は悪ではないが、「責務が曖昧な塊」になるのは悪。UIの責務単位で分割する。
思想(判断ルール)
- 早すぎる抽象化(命名・共通クラス化)を避ける。まず具体で組み立てる。
- “同じ見た目が3回以上”出たら抽象化を検討する(コンポーネント化/共通化)。
- tokens を先に決める(色/余白/タイポ)。揺れはtokensで止め、場当たり値を増やさない。
- クラスを読む負担が増えたら、構造(コンポーネント)で解決する。CSSの抽象で解決しない。
- UIの意図(レイアウト/間隔/強調)を、クラスの並びとして可視化する。
Related skills
More from mae616/ai-tech-knowledge
react
React/Next.jsプロジェクトで、UI=計算モデル(コンポーネント/状態/レンダリング)を軸に、設計・実装・レビュー・性能改善の判断を整理する。React、Next.js、JSX、コンポーネント設計、useState/useEffect、状態管理、Server Components、SSR/SSG/Streaming、App Router、バンドル最適化、再レンダリング問題に関する相談で必ず使うこと。ユーザーが「コンポーネントの分割」「stateの置き場所」「パフォーマンスが遅い」「RSCの使い分け」と言った場合にも適用する。
3playwright
Playwright E2Eテストフレームワークの判断軸。ユーザー視点のロケーター選択・自動待機・テスト分離・CI最適化を公式ベストプラクティスに沿って整理する。Playwright、E2Eテスト、ブラウザテスト、インテグレーションテスト、getByRole、ロケーター設計、テストの安定性、CI上のテスト失敗に関する相談で必ず使うこと。ユーザーが「テストが不安定」「CIでだけ落ちる」「ブラウザテストを書きたい」「ログインフローをテスト」と言った場合、Playwrightが技術スタックに含まれていれば適用する。
2