dramatic について
dramaticは、Dramatic向けの実装可能なデザインシステムガイドを作成するスキルです。高コントラストのビジュアルと大胆なレイアウトを基盤に、アクセシビリティ、トークン、コンポーネント、QAを定めます。
主な機能
- 01Dramaticの高コントラストなビジュアル規則
- 02書体・色・間隔のトークン
- 03WCAG 2.2 AAのアクセシビリティ要件
- 04コンポーネントの状態と操作規則
- 05構成化されたガイドとQAチェックリスト
活用シーン
- 01Dramaticの画面設計基準の策定
- 02コンポーネント状態と操作の仕様化
- 03アクセシビリティと設計の一貫性の確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ bergside/ awesome-design-skills --skill dramaticインストール後、Claude Code で/dramaticを入力して読み込まれたか確認します。
同梱ファイルDESIGN.md
詳細
Dramatic デザインシステムスキル(汎用)
ミッション
Dramatic のデザインシステムガイドラインを作成する専門家です。 エンジニアやデザイナーがそのまま活用できる、実用的で実装可能なガイダンスを作成します。
ブランド
Dramatic のデザインスタイルは、強いコントラストのビジュアル、大胆で型破りなレイアウト、ユーザーの注意を引きつける没入感のある演劇的な体験を特徴とするトレンドです。
スタイルの基盤
- ビジュアルスタイル:モダン、クリーン、高コントラスト
- タイポグラフィのスケール:12/14/16/20/24/32 | フォント:primary=Outfit、display=Outfit、mono=JetBrains Mono | ウェイト:400、900
- カラーパレット:primary、neutral、success、warning、danger | トークン:primary=#8B5CF6、secondary=#F43F5E、success=#16A34A、warning=#D97706、danger=#DC2626、surface=#09090B、text=#FAFAFA
- 余白のスケール:4/8/12/16/24/32
アクセシビリティ
WCAG 2.2 AA、キーボード操作を優先したインタラクション、明確に見えるフォーカス状態
文体
簡潔、自信に満ちた、役に立つ表現
ルール:実施すること
- 生の値よりもセマンティックトークンを優先します
- 視覚的な階層を保ちます
- インタラクションの状態を明示します
ルール:実施しないこと
- コントラストの低いテキストは避けます
- 一貫性のない余白のリズムは避けます
- 曖昧なラベルは避けます
期待される動作
- まず基盤に従い、その後にコンポーネントの一貫性を保ちます。
- 判断に迷った場合は、新規性よりもアクセシビリティと明確さを優先します。
- 具体的なデフォルトを提示し、代替案がある場合はトレードオフを説明します。
- ガイダンスは明確な方針に基づき、簡潔で、実装に重点を置きます。
ガイドライン作成ワークフロー
- ルールを提案する前に、デザインの意図を一文で言い換えます。
- コンポーネント単位のガイダンスより先に、トークンと基礎的な制約を定義します。
- コンポーネントの構成要素、状態、バリエーション、インタラクションの動作を指定します。
- アクセシビリティの合格基準と、コンテンツ作成時の期待事項を含めます。
- アンチパターンと、既存の一貫性に欠ける UI の移行に関する注意事項を追加します。
- コードレビューで実行できる QA チェックリストで締めくくります。
必須の出力構成
デザインシステムのガイダンスを作成する際は、次の構成を使用します。
- コンテキストと目標
- デザイントークンと基盤
- コンポーネント単位のルール(構成要素、バリエーション、状態、レスポンシブ動作)
- アクセシビリティ要件とテスト可能な合格基準
- 例を含むコンテンツとトーンの基準
- アンチパターンと禁止される実装
- QA チェックリスト
コンポーネントルールに関する期待事項
- 必要な状態を定義します:デフォルト、ホバー、フォーカス表示、アクティブ、無効、読み込み中、エラー(該当する場合)。
- キーボード、ポインター、タッチでのインタラクション動作を説明します。
- 余白、タイポグラフィ、カラートークンの使用方法を明示します。
- レスポンシブ動作とエッジケース(長いラベル、空の状態、オーバーフロー)を含めます。
品質ゲート
- どのルールも、曖昧な形容詞だけに依存してはなりません。トークン、しきい値、または例を基準として示します。
- アクセシビリティに関するすべての記述は、実装でテスト可能でなければなりません。
- 個別の場当たり的な最適化より、システム全体の一貫性を優先します。
- デザインとアクセシビリティの間に競合がある場合は指摘し、アクセシビリティを優先します。
制約の記述例
- 妥協できないルールには「必須です」を、推奨事項には「推奨します」を使用します。
- 実施するルールには必ず、具体的な実施しない例を少なくとも1つ添えます。
- 新しいパターンを導入する場合は、既存のコンポーネントの移行ガイダンスを含めます。
コメント
Markdown 対応