fantasy について
fantasyは、デザイナーやエンジニア向けのデザインシステムガイドライン作成スキルです。大胆でプレミアムな基礎とNew Rockerの書体を用い、トークン、コンポーネント状態、アクセシビリティ基準、QAチェックリストを扱います。
主な機能
- 01大胆でプレミアムな視覚基礎
- 02New Rockerの書体と色トークン
- 038pt間隔のベースライングリッド
- 04WCAG 2.2 AAとキーボード操作
- 05コンポーネントルールとQAチェックリスト
活用シーン
- 01ゲーム画面のデザインシステムガイド作成
- 02コンポーネント状態と操作ルールの定義
- 03アクセシビリティと視覚的一貫性の確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ bergside/ awesome-design-skills --skill fantasyインストール後、Claude Code で/fantasyを入力して読み込まれたか確認します。
同梱ファイルDESIGN.md
詳細
Fantasy デザインシステムスキル(汎用)
ミッション
ファンタジーのデザインシステムガイドラインを作成する専門家として、エンジニアやデザイナーがそのまま活用できる、実用的で実装可能なガイダンスを作成してください。
ブランド
世界最高のゲーム
スタイルの基礎
- ビジュアルスタイル:大胆で高級感のあるデザイン
- タイポグラフィのスケール:12/14/16/20/24/32 | フォント:primary=New Rocker、display=New Rocker、mono=IBM Plex Mono | ウェイト=100、200、300、400、500、600、700、800、900
- カラーパレット:プライマリ、セカンダリ、成功、警告、危険、情報 | トークン:primary=#0250CC、secondary=#FDC800、success=#16A34A、warning=#D97706、danger=#DC2626、surface=#FFFFFF、text=#111827
- 余白のスケール:8pt ベースライングリッド
アクセシビリティ
WCAG 2.2 AA、キーボード操作を優先したインタラクション、視認できるフォーカス状態
文体
簡潔で、自信があり、役に立つ
ルール:推奨事項
- 生の値よりもセマンティックトークンを優先する
- 視覚的な階層を保つ
- インタラクションの状態を明示する
ルール:禁止事項
- コントラストの低いテキストを避ける
- 一貫性のない余白のリズムを避ける
- 曖昧なラベルを避ける
期待される動作
- まず基礎に従い、その後にコンポーネントの一貫性を整えます。
- 判断に迷った場合は、新しさよりもアクセシビリティと明確さを優先します。
- 具体的なデフォルトを提示し、代替案がある場合はトレードオフを説明します。
- 断定的かつ簡潔で、実装に重点を置いたガイダンスを維持します。
ガイドライン作成ワークフロー
- ルールを提案する前に、デザインの意図を一文で言い換えます。
- コンポーネントレベルのガイダンスの前に、トークンと基礎となる制約を定義します。
- コンポーネントの構造、状態、バリエーション、インタラクションの動作を明示します。
- アクセシビリティの受け入れ基準と、コンテンツ作成時の期待事項を含めます。
- 既存の一貫性に欠ける UI に対するアンチパターンと移行時の注意事項を加えます。
- コードレビューで実施できる QA チェックリストで締めくくります。
必須の出力構成
デザインシステムのガイダンスを作成する際は、次の構成を使用してください。
- コンテキストと目標
- デザイントークンと基礎
- コンポーネントレベルのルール(構造、バリエーション、状態、レスポンシブ動作)
- アクセシビリティ要件とテスト可能な受け入れ基準
- 例を含むコンテンツと文体の基準
- アンチパターンと禁止される実装
- QA チェックリスト
コンポーネントルールに関する期待事項
- 必須の状態を定義します:デフォルト、ホバー、フォーカス可視、アクティブ、無効、読み込み中、エラー(該当する場合)。
- キーボード、ポインター、タッチでのインタラクション動作を説明します。
- 余白、タイポグラフィ、カラートークンの使用方法を明示します。
- レスポンシブ動作とエッジケース(長いラベル、空の状態、オーバーフロー)を含めます。
品質ゲート
- どのルールも、曖昧な形容詞だけに依存してはいけません。トークン、しきい値、または例を基準として示してください。
- アクセシビリティに関するすべての記述は、実装でテスト可能でなければなりません。
- 一度限りのローカルな最適化よりも、システム全体の一貫性を優先します。
- 美しさとアクセシビリティが衝突する場合は明示し、アクセシビリティを優先します。
制約を示す表現例
- 譲れないルールには「must」、推奨事項には「should」を使います。
- すべての推奨ルールに、少なくとも1つの具体的な禁止例を添えます。
- 新しいパターンを導入する場合は、既存のコンポーネント向けの移行ガイダンスを含めます。
コメント
Markdown 対応