mcpField
T
taste-skill

taste-skill

github.com/cowork-osデザイン・UI51787 回インストール今日更新
リポジトリ

taste-skill について

Taste Skill は、意図の明確なビジュアル、レイアウト、インタラクションの方針に沿ってフロントエンド実装を導きます。独自性のあるデザインを求めるタスク向けに、依存関係、モーション、レスポンシブ対応、納品の実務ルールも示します。

主な機能

  1. 01ビジュアル・レイアウト・操作方針の策定
  2. 02デザイン、モーション、密度の調整
  3. 03インポート前の依存関係確認
  4. 04画面状態の網羅
  5. 05パフォーマンス上の制約

活用シーン

  1. 01要件から個性のあるフロントエンドを構築
  2. 02意図のある操作やモーションを追加
  3. 03納品前にレスポンシブな画面状態を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/cowork-os/cowork-os --skill taste-skill

インストール後、Claude Code で/taste-skillを入力して読み込まれたか確認します。

詳細

Taste Skill

安全なデフォルトではなく、明確なフロントエンドの美学が必要な場合にこのスキルを使用します。

目標は「十分にきれい」ではありません。意図が感じられ、プレミアムで、汎用的な LLM の出力と容易に見分けられるフロントエンドを目指します。

1. 現在の基本設定

  • DESIGN_VARIANCE: 8 1 = 対称的で落ち着いたデザイン, 10 = 非対称で実験的なデザイン
  • MOTION_INTENSITY: 6 1 = ほぼ静止, 10 = 映画のようにダイナミックに反応
  • VISUAL_DENSITY: 4 1 = 余白のあるギャラリー, 10 = 情報が密集したコックピット

これらは固定値ではなく、調整用のダイヤルとして扱います。

  • ユーザーにこのファイルの編集を求めないでください。
  • 依頼内容に合わせてダイヤルを調整します。ユーザーが落ち着いた出力を求めている場合は値を下げ、大胆な出力を求めている場合は値を上げます。
  • ダイヤルを使って、レイアウト、アニメーション、余白、カードの使い方を決めます。

2. 必須の作業モデル

コーディングの前に、次の3点を明確にします。

  1. ビジュアルの主題 雰囲気、素材感、エネルギーを1文で表現します。
  2. レイアウトの主題 非対称、トリミング、余白、動きの重なり、分割型ヒーロー、ベントー風のリズムなど、ページを印象的にする要素を示します。
  3. インタラクションの主題 インターフェースの印象を実質的に変える動きを2つか3つ示します。

そのうえで、実際のコードを実装します。デザインについてのコメントだけで終わらせないでください。

  • 「TODO: ここにアニメーションを追加」のようなプレースホルダーを残さないでください。
  • 実際にリリースするコンポーネントについて、見せかけのコードスニペットを出力しないでください。
  • 依頼内容が明確になった後は、当然のデザイン上の判断について許可を求めないでください。

3. アーキテクチャと依存関係のルール

ユーザーが明示的に別のものを求めていない限り、React または Next.js を優先します。

依存関係の確認

サードパーティ製パッケージをインポートする前に、次のことを行います。

  • package.json を確認します。
  • パッケージが含まれていない場合は、使用する前に正確なインストールコマンドを示します。
  • framer-motion、lucide-react、zustand、フォントパッケージがすでにインストールされていると決めつけないでください。
React と Next.js のルール
  • Next.js では、デフォルトでサーバーセーフな構成にします。
  • グローバル状態をサーバーコンポーネントに置かないでください。
  • モーションや高度にインタラクティブな動作が必要な場合は、独立したクライアントコンポーネントに分離します。
  • 1つのリーフコンポーネントで管理できるアニメーションロジックを、ツリー全体に分散させないでください。
スタイリングのルール
  • プロジェクトが明らかに別の方式を採用している場合を除き、ほとんどのスタイリングに Tailwind を使用します。
  • 設定に関わるコードを書く前に、プロジェクトが Tailwind v3 と v4 のどちらを使用しているか確認します。
  • v3 のプロジェクトで v4 のパターンを使用しないでください。
アイコンのルール
  • プロジェクトが対応している場合は、@phosphor-icons/react または @radix-ui/react-icons を優先します。
  • ページ全体でアイコンの線幅を統一します。
厳守事項
  • コード、マークアップ、UI の文言、代替テキストに絵文字を使用しないでください。
  • モバイル対応が必要なレイアウトでは、ヒーローに h-screen を使用しないでください。min-h-[100dvh] を使用します。
  • Grid でよりすっきりレイアウトできる場合は、Flexbox のパーセンテージ計算を使用しないでください。

4. デザインエンジニアリングの指針

LLM は使い古されたおなじみの UI パターンに流されがちです。先回りしてそれを修正してください。

タイポグラフィ
  • 見出しは、大きく、引き締まり、力強い印象を基本とします。
  • プレミアムまたはクリエイティブなデザインが求められる場合は、Inter、Arial、Roboto のような汎用フォントスタックや、システムのデフォルトフォントを避けます。
  • Geist、Outfit、Cabinet Grotesk、Satoshi など、個性がありながらも節度のあるディスプレイフォントを優先します。
  • ダッシュボードやソフトウェア UI では、セリフ体のディスプレイフォントを使用しないでください。
  • 力強いディスプレイ書体に、控えめな補助書体または等幅書体を組み合わせます。
色
  • 控えめなニュートラルカラーをベースに、メインのアクセントカラーを1色使用します。
  • アクセントカラーの彩度は抑えます。
  • ありがちな AI 風の紫や青のグロー表現は避けます。
  • 暖色系と寒色系のグレーを無秩序に混在させないでください。
レイアウト

DESIGN_VARIANCE > 4 の場合:

  • ヒーロー全体をデフォルトで中央揃えにしないでください。
  • ファーストビューで「見出し+2つのボタン+カードグリッド」という構成を避けてください。
  • 分割画面、ずらしたコンテンツ、非対称なネガティブスペース、固定配置のメディア、グリッドを崩した構成を優先します。
サーフェスとカード
  • カードをデフォルトにしないでください。
  • 階層やインタラクションを伝えるためにエレベーションが必要な場合に限り、カードを使用してください。
  • 情報密度の高いダッシュボードでは、カードを延々と並べるのではなく、区切り線、枠線のリズム、余白を優先してください。
  • カードを取り除いても意味が変わらないなら、取り除いてください。
フォームと状態

本格的なサーフェスには、次のすべてのインタラクション状態が必要です。

  • 読み込み状態
  • 空の状態
  • エラー状態
  • 成功状態
  • 触覚的なアクティブ状態

フォームでは、次のようにします。

  • ラベルを入力欄の上に配置する
  • 補足テキストは任意ですが、あると便利です
  • エラーテキストを入力欄の下に表示する
  • 一貫した縦方向の余白を保つ

5. モーションシステム

モーションは存在感と階層を生み出すものであり、ノイズになってはいけません。

MOTION_INTENSITY <= 3 の場合:

  • モーションは表示時、ホバー時、小さな操作感の変化に限定します

MOTION_INTENSITY > 5 の場合:

  • 継続的なマイクロインタラクションを追加します
  • 表示を段階的にずらします
  • スプリングベースのモーションを使用します
  • 少なくとも1つのインタラクションに、物理的な反応を感じられる動きを取り入れます
推奨するモーションパターン
  • 段階的な表示
  • レイアウトのトランジション
  • ホバーに反応するボタン
  • スクロールに連動する奥行きの変化
  • アクティブなインターフェースのための文字やシマーのループ
  • 浮遊する、または呼吸するようなステータス表示
マグネティックインタラクションのルール

カーソルに反応するマグネティックな挙動を実装する場合:

  • フレームごとのカーソル更新に React の useState を使用しないでください
  • モーション値など、レンダーループに安全なプリミティブを優先してください
モーションの品質基準
  • デフォルトで線形のモーションにしないでください
  • 目的のない、むやみな無限アニメーションは使用しないでください
  • リズム、フォーカス、操作感の向上につながらない、装飾だけのアニメーションは使用しないでください

6. マテリアリティと視覚的な質感

デザインでガラスや半透明のレイヤーが求められる場合:

  • 生の backdrop-blur だけに頼らないでください
  • 控えめな内側の境界線を追加してください
  • 控えめな内側のハイライトまたは内側のシャドウを追加してください

雰囲気づくりは意図的に行ってください。

  • グラデーションメッシュ
  • ノイズオーバーレイ
  • ソフトなビネット
  • レイヤー状の透明表現
  • 調整されたシャドウ

ただし、次の点に注意してください。

  • 粒状感やノイズは、スクロールするコンテナーではなく、固定オーバーレイに配置してください
  • すべてのセクションを特殊効果にしないでください

7. パフォーマンスのガードレール

パフォーマンスの悪いプレミアムな UI も、やはり悪い UI です。

  • top、left、width、height ではなく、transform と opacity をアニメーションしてください。
  • コストの高いエフェクトは、大きなスクロール面では使用しないでください。
  • z-index をむやみに増やさないでください。
  • 必要に応じて、継続的に動くアイランドをメモ化してください。
  • 特別なシーンに GSAP や Three.js を使用する場合は、分離してください。同じコンポーネントツリー内で、重いモーションシステムを不用意に混在させないでください。

8. パターンライブラリ

弱いアイデアをたくさん使うのではなく、強いアイデアを少数選んでください。

ファーストビューに適したパターン
  • 固定されたテキストと、主役となる1つのメディア面を組み合わせた分割ヒーロー
  • タイルの比重に変化をつけた非対称なベントーセクション
  • 大きな文字と控えめな補足コピーを使ったエディトリアルなランディングページ
  • 落ち着いた構成で装飾的なクロームをほとんど使わず、1つの強いアクセントを備えたプロダクト UI
効果的なモーションのアイデア
  • スティッキースタック
  • ホバーに反応する方向性のある塗りつぶし
  • 最終形状に合ったシマースケルトン
  • タイプライターまたはコマンド入力のループ
  • 明確なストーリー上の目的を持つカバーフローまたは水平ストリーム
  • フローティングツールバーまたは共有要素のトランジション
デフォルトでは避けるパターン
  • フローティングするダッシュボードのモックアップを置いた、中央揃えの SaaS ヒーロー
  • すべてのヒーローの下に統計情報の帯を置く
  • 埋め草としてのロゴクラウド
  • 白地に紫のグラデーション
  • すべてのセクションにカードグリッドを使う
  • まとまりのないフォントの個性の混在

9. 納品基準

このスキルを使用する場合、実装は次の状態でユーザーに提供してください。

  • 実際に動作するコード
  • 明確なビジュアルの主張
  • 一貫したモーション表現
  • デスクトップとモバイルの両方で破綻しないレスポンシブな挙動
  • パッケージが不足している場合は、依存関係の呼び出しを明示すること

次のことはしないでください。

  • 美意識のシステムを適用せず、説明するだけにとどめる
  • 汎用的なコンポーネントライブラリのデフォルトに頼る
  • 「主なアイデア」は完成したとして、未完成のセクションを残す

10. 事前チェックリスト

仕上げる前に、次のリストに照らして結果を確認してください。

  • 最初のビューポートに、明確なビジュアルのアイデアが一つありますか?
  • タイポグラフィは、デフォルト設定ではなく、意図して選んだように感じられますか?
  • アクセントカラーは節度をもって使われていますか?
  • すべての影を取り除いても、意図的にデザインされた印象を保てますか?
  • カードは、作りやすいからではなく、必要だから使われていますか?
  • モーションは認識できる一方で、制御されていますか?
  • 関連する箇所で、読み込み中、空、エラー、アクティブの各状態に対応していますか?
  • 特にビューポートの高さやオーバーフローなど、モバイルでの安定性に対処していますか?
  • 外部依存関係をインポートする前に確認しましたか?
  • 出力は、コンポーネントを組み合わせただけではなく、デザインされたインターフェースのように感じられますか?

コメント