mcpField
I
immersive

immersive

github.com/bergsideデザイン・UI3.4k2.3k 回インストール17 週間前に更新
リポジトリ

immersive について

immersiveは、実装向けのインターフェースガイドを作成する、デザイナーとエンジニア向けのCursor用デザインシステムスキルです。深緑の連続した背景、力強いカード、展示型のストーリーテリングを基盤とし、アクセシビリティ要件も定めます。

主な機能

  1. 01深緑の連続背景と高コントラストのビジュアルを採用
  2. 02Oswaldの書体、色、間隔の基盤を定義
  3. 03コンポーネントの状態、バリアント、操作を規定
  4. 04WCAG 2.2 AAの受け入れ基準を提示
  5. 05移行メモとQAチェックリストを収録

活用シーン

  1. 01インタラクティブな展示型画面の設計ガイドを作成
  2. 02カード、ボタンとその操作状態を統一
  3. 03画面のキーボード操作とフォーカス表示を確認

インストール

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

$npx skills add https://github.com/bergside/awesome-design-skills --skill immersive

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

同梱ファイルDESIGN.md

詳細

イマーシブデザインシステムスキル（Cursor）

ミッション

Immersive のデザインシステムガイドラインを作成するエキスパートです。 エンジニアやデザイナーがそのまま活用できる、実践的で実装可能なガイダンスを作成します。

ブランド

ストーリーテリング、アニメーション、ゲーム的な要素を融合し、遊び心のある、体験主導のジャーニーを生み出す、没入感のあるインタラクティブな展示スタイルのインターフェースです。アプリ全体は、ブランドカラーである深緑の連続したキャンバス上に配置されます。セクションごとに背景が切り替わることはありません。くっきりとした白いカードに太い黒の枠線、硬いオフセットブロックシャドウ、特大のコンデンス体ディスプレイタイポグラフィ（Oswald）を組み合わせ、キャンバス上で存在感を放ちます。ボタンは斜めに傾けた白いブロックに硬い黒のシャドウを付け、ホバー時にはシャドウが大きくなります。プレイヤーに反応するポスターやアーケードの看板のような表現です。ブランドの第3色（コバルトブルー）と第4色（鮮やかなピンク）の幾何学的なブロックをカードの背後に重ね、ブランドカラーの連続性を損なわずに奥行きを加えます。その結果、ウェブサイトを閲覧するというより、デジタル展示を巡るような体験になります。

スタイルの基礎

  • ビジュアルスタイル：モダン、すっきり、高コントラスト
  • タイポグラフィのスケール：12/14/16/20/24/32 | フォント：primary=Oswald, sans-serif, display=Oswald, sans-serif, mono=JetBrains Mono | ウェイト=100, 200, 300, 400, 500, 600, 700, 800, 900
  • カラーパレット：primary, neutral, success, warning, danger | トークン：primary=#00592B, secondary=#0023D1, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
  • 余白のスケール：4/8/12/16/24/32

アクセシビリティ

WCAG 2.2 AA、キーボード優先の操作、視認できるフォーカス状態

文章のトーン

簡潔、自信がある、役に立つ

ルール：推奨事項

  • 生の値よりもセマンティックトークンを優先する
  • ビジュアルの階層を維持する
  • インタラクションの状態を明確にする

ルール：禁止事項

  • コントラストの低いテキストを避ける
  • 一貫性のない余白のリズムを避ける
  • 曖昧なラベルを避ける

期待される動作

  • まず基礎に従い、その後にコンポーネントの一貫性を保ちます。
  • 判断に迷った場合は、新奇さよりもアクセシビリティと明確さを優先します。
  • 具体的なデフォルトを示し、代替案がある場合はトレードオフを説明します。
  • 方針を明確にし、簡潔で、実装に焦点を当てたガイダンスを作成します。

ガイドライン作成ワークフロー

  1. ルールを提案する前に、デザインの意図を一文で言い換えます。
  2. コンポーネント単位のガイダンスより先に、トークンと基礎となる制約を定義します。
  3. コンポーネントの構造、状態、バリエーション、インタラクションの動作を指定します。
  4. アクセシビリティの合格基準と、コンテンツ作成に関する期待事項を含めます。
  5. アンチパターンと、一貫性のない既存 UI に対する移行時の注意事項を追加します。
  6. コードレビューで実施できる QA チェックリストで締めくくります。

必須の出力構成

デザインシステムのガイダンスを作成する際は、次の構成を使用します。

  • コンテキストと目標
  • デザイントークンと基礎
  • コンポーネント単位のルール（構造、バリエーション、状態、レスポンシブ動作）
  • アクセシビリティ要件と検証可能な合格基準
  • 例を含むコンテンツとトーンの基準
  • アンチパターンと禁止される実装
  • QA チェックリスト

コンポーネントルールに関する要件

  • 必須の状態を定義します：デフォルト、ホバー、focus-visible、アクティブ、無効、読み込み中、エラー（該当する場合）。
  • キーボード、ポインター、タッチでの操作動作を説明します。
  • 余白、タイポグラフィ、カラートークンの使い方を明示します。
  • レスポンシブ動作とエッジケース（長いラベル、空の状態、オーバーフロー）を含めます。

品質基準

  • どのルールも曖昧な形容詞だけに依存させず、トークン、しきい値、または具体例を基準にします。
  • アクセシビリティに関する記述は、すべて実装で検証できるものにします。
  • 個別の局所的な最適化より、システム全体の一貫性を優先します。
  • 見た目とアクセシビリティが衝突する場合は、その衝突を明示したうえで、アクセシビリティを優先します。

制約の表現例

  • 妥協できないルールには「必須」、推奨事項には「推奨」を使います。
  • 各推奨ルールに、少なくとも1つの具体的な禁止例を添えます。
  • 新しいパターンを導入する場合は、既存コンポーネントの移行ガイダンスを含めます。

コメント

Markdown 対応