mcpField
D
doodle

doodle

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

doodle について

doodleは、デザイナーやエンジニア向けの汎用デザインシステムガイド作成スキルです。遊び心のある落書き風の基礎を軸に、実装可能なコンポーネント規則と検証可能なアクセシビリティ要件をまとめます。

主な機能

  1. 01落書き風のビジュアル規則
  2. 02書体・色・間隔のトークン
  3. 03WCAG 2.2 AA要件
  4. 04コンポーネントの状態と操作規則
  5. 05構成化されたガイドとQAチェックリスト

活用シーン

  1. 01ブランドに沿った画面規則の策定
  2. 02コンポーネントの操作とレスポンシブ動作の指定
  3. 03検証可能なアクセシビリティ基準の設定
  4. 04UIのアンチパターンと移行要件の整理

インストール

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

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

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

同梱ファイルDESIGN.md

詳細

Doodle デザインシステムのスキル(ユニバーサル)

ミッション

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

ブランド

落書き、スケッチ、手書き風フォント、不完全な線を活用し、感情的なつながりと、ありのままで芸術的な雰囲気を育む、創造的で遊び心のあるカジュアルなスタイルです。

スタイルの基礎

  • ビジュアルスタイル:遊び心のあるもの
  • タイポグラフィのスケール:14/16/18/24/32/40 | フォント:primary=Delius Swash Caps、display=Delius Swash Caps、mono=JetBrains Mono | ウェイト:100、200、300、400、500、600、700、800、900
  • カラーパレット:primary、secondary、neutral、success、warning、danger | トークン:primary=#49B6E5、secondary=#263D5B、success=#16A34A、warning=#D97706、danger=#DC2626、surface=#FFFFFF、text=#111827
  • 余白のスケール:4/8/12/16/24/32

アクセシビリティ

WCAG 2.2 AA、キーボード操作を優先したインタラクション、視認可能なフォーカス状態

文章のトーン

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

ルール:推奨事項

  • 生の値よりセマンティックトークンを優先します
  • 視覚的な階層を維持します
  • インタラクションの状態を明確にします

ルール:禁止事項

  • コントラストの低いテキストは避けます
  • 余白のリズムに一貫性がない状態は避けます
  • 曖昧なラベルは避けます

期待される動作

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

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

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

必須の出力構成

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

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

コンポーネントルールに求められる事項

  • 必要な状態を定義します:default、hover、focus-visible、active、disabled、loading、error(該当するもの)。
  • キーボード、ポインター、タッチでのインタラクションの動作を説明します。
  • 余白、タイポグラフィ、カラートークンの使い方を明示します。
  • レスポンシブな動作とエッジケース(長いラベル、空の状態、オーバーフロー)を含めます。

品質ゲート

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

制約を表す文言の例

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

コメント