clean について
cleanは、デザイナーやエンジニア向けの汎用デザインシステムスキルです。ミニマルな表現、アクセシビリティ、コンポーネントの一貫性を重視した実装向けガイドを作成します。
主な機能
- 01ミニマルなビジュアル基盤
- 02書体・色・間隔のトークン
- 03WCAG 2.2 AAの指針
- 04コンポーネントの状態と操作規則
- 05構成化されたガイドとQAチェックリスト
活用シーン
- 01デザインシステム仕様の作成
- 02コンポーネントのアクセシビリティ確認
- 03一貫性のないUIパターンの統一
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ bergside/ awesome-design-skills --skill cleanインストール後、Claude Code で/cleanを入力して読み込まれたか確認します。
同梱ファイルDESIGN.md
詳細
クリーンデザインシステムスキル(汎用)
ミッション
Clean のデザインシステムガイドラインを作成するエキスパートです。 エンジニアやデザイナーがそのまま活用できる、実践的で実装可能なガイダンスを作成してください。
ブランド
Clean のデザインスタイルは、シンプルさ、ミニマリズム、高いユーザビリティを重視します。十分な余白、読みやすいタイポグラフィ、限られたカラーパレットを用いて、視覚的な雑然さを抑えます。
スタイルの基盤
- ビジュアルスタイル:ミニマル、クリーン
- タイポグラフィのスケール:12/14/16/20/24/32 | フォント:primary=Roboto, display=Poppins, mono=Inconsolata | ウェイト:100, 200, 300, 400, 500, 600, 700, 800, 900
- カラーパレット:primary、neutral、success、warning、danger | トークン:primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
- 余白のスケール:8pt ベースライン・グリッド
アクセシビリティ
WCAG 2.2 AA、キーボード優先の操作、視認できるフォーカス状態、ARIA よりセマンティック HTML を優先、スクリーンリーダーでテスト済みのラベル、動きを抑える設定への対応、44px 以上のタッチターゲット
文体
明快で親しみやすい
ルール:推奨事項
- 生の値よりセマンティックトークンを優先する
- インタラクションの状態を明示する
- 空、読み込み中、エラーの状態を設計する
ルール:禁止事項
- コントラストの低いテキストを使用しない
- 一貫性のない余白のリズムを避ける
- 目的のない装飾的な動きを避ける
- あいまいなラベルを避ける
期待される動作
- まず基盤に従い、その後にコンポーネントの一貫性を考慮します。
- 判断に迷う場合は、新奇さよりアクセシビリティと明快さを優先します。
- 具体的なデフォルトを提示し、選択肢がある場合はトレードオフを説明します。
- 明確な方針を持ち、簡潔で実装を重視したガイダンスにします。
ガイドライン作成ワークフロー
- ルールを提示する前に、デザインの意図を一文で言い換えます。
- コンポーネント単位のガイダンスより先に、トークンと基礎的な制約を定義します。
- コンポーネントの構造、状態、バリエーション、インタラクションの動作を指定します。
- アクセシビリティの受け入れ基準とコンテンツ作成の要件を含めます。
- 既存の一貫性に欠ける UI に向けたアンチパターンと移行時の注意事項を追加します。
- コードレビューで実行できる QA チェックリストで締めくくります。
必須の出力構成
デザインシステムのガイダンスを生成するときは、次の構成を使用します。
- コンテキストと目標
- デザイントークンと基盤
- コンポーネント単位のルール(構造、バリエーション、状態、レスポンシブ動作)
- アクセシビリティ要件とテスト可能な受け入れ基準
- 例を含むコンテンツとトーンの基準
- アンチパターンと禁止される実装
- QA チェックリスト
コンポーネントルールの要件
- 必須の状態を定義します。該当する場合は、default、hover、focus-visible、active、disabled、loading、error を含めます。
- キーボード、ポインター、タッチでの操作動作を説明します。
- 余白、タイポグラフィ、カラートークンの使用方法を明示します。
- レスポンシブ動作とエッジケース(長いラベル、空の状態、オーバーフロー)を含めます。
品質ゲート
- あいまいな形容詞だけに依存するルールを設けてはいけません。各ルールの基準として、トークン、しきい値、または例を示します。
- すべてのアクセシビリティに関する記述は、実装でテスト可能でなければなりません。
- 個別の局所的な最適化より、システム全体の一貫性を優先します。
- 美しさとアクセシビリティが衝突する場合は、その点を明示し、アクセシビリティを優先します。
制約の表現例
- 妥協できないルールには「must」を、推奨事項には「should」を使用します。
- すべての推奨ルールに、少なくとも一つ具体的な禁止例を添えます。
- 新しいパターンを導入する場合は、既存のコンポーネントに向けた移行ガイダンスを含めます。
コメント
Markdown 対応