From design-plugin
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント(要件定義・ブランドガイドライン)からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク(Double Diamond・Atomic Design・Design Tokens 3層)の適用、暗黙的デザイン判断の形式知化(DDR/QOC/RFC)、UIインベントリ収集(手動+MCP自動化)を統合する。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。
How this skill is triggered — by the user, by Claude, or both
Slash command
/design-plugin:design-system-builderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
デザインシステムの構築・運用を体系的に行う。Double Diamondの発散→収束モデルで進行し、各フェーズの成果物を契約として管理する。
デザインシステムの構築・運用を体系的に行う。Double Diamondの発散→収束モデルで進行し、各フェーズの成果物を契約として管理する。
Phase 1: 発見(Discover) → UIインベントリ、課題洗い出し
→ Phase 2: 定義(Define) → 設計原則、判断基準の収束
→ Phase 3: 基盤設計(Develop) → Design Tokens、Foundation定義
→ Phase 4: コンポーネント構築(Deliver) → Atomic Design構造化
→ Phase 5: 採用・移行(Adopt) → 段階リリース、既存UIの移行
→ Phase 6: 運用(Operate) → ガバナンス、継続改善
目的: 現状の設計資産と課題を発散的に収集する。
既存UIの全要素をスクリーンショット+CSSプロパティで収集・分類する。
手動アプローチ:
自動化アプローチ(MCP連携): Playwright MCP + Chrome DevTools MCP で定量的に収集可能。 自動収集を使う場合に参照 → references/ui-inventory.md
要件定義・ブランドガイドラインを3カテゴリに分離:
| カテゴリ | 内容 | 例 |
|---|---|---|
| 事実 | 変更不可の制約 | ブランドカラー #003366、フォント Noto Sans |
| 制約 | 技術的・ビジネス的制限 | WCAG 2.1 AA必須、iOS/Android両対応 |
| 解釈 | チームの判断が必要 | 「親しみやすい」トーンの具体化 |
デザイナー・エンジニア・PM・マーケティング等から課題を収集する:
ui-inventory.json — UI要素の棚卸し結果design-brief.md — 対象・スコープ・制約・課題の要約目的: 発散した情報を収束させ、判断基準を確立する。
暗黙のデザイン判断を形式知化する:
カード名: [判断の名前]
意図: なぜこの判断をしたか
適用条件: いつ使うか
禁止条件: いつ使わないか
例外: 例外的に許容するケース
根拠: エビデンス(ユーザーテスト結果、a11y基準等)
3〜5個のデザイン原則に収束させる。衝突時の優先順位を明示する。
例:
1. アクセシビリティ > 美しさ
2. 一貫性 > 個別最適
3. シンプルさ > 機能の網羅性
設計判断を記録するプロセスを確立する。 DDRの書き方・QOC・RFC運用が必要な場合に参照 → references/design-decision-records.md
design-principles.md — 優先順位付きデザイン原則decision-log/DDR-NNN.md — DDRファイル(DDRテンプレートに準拠)目的: Design Tokensと基盤要素を定義する。
Layer 1: Global Tokens(基盤)
色の生値、フォントサイズの生値
例: blue-500: #3B82F6, font-size-16: 16px
Layer 2: Semantic Tokens(意味)
意図を表現するエイリアス
例: color-primary: {blue-500}, text-body: {font-size-16}
Layer 3: Component Tokens
コンポーネント固有のバインディング
例: button-bg-primary: {color-primary}
原則: コンポーネントはLayer 3のみ参照する。Layer 1の直参照は禁止。
| 要素 | 定義内容 | トークン例 |
|---|---|---|
| カラー | Primary/Secondary/Semantic + 明度スケール(50-950) | color-primary-500 |
| タイポグラフィ | フォント、サイズスケール、行間、ウェイト | font-size-lg |
| スペーシング | 4px/8pxベースのスケール | space-4: 16px |
| エレベーション | シャドウ、レイヤリング | shadow-md |
| ボーダーラディウス | 角丸スケール | radius-md: 8px |
| モーション | デュレーション、イージング | duration-fast: 150ms |
| ブレークポイント | レスポンシブ基準 | breakpoint-md: 768px |
W3C Design Tokens Format(2025.10安定版)に準拠した tokens.json を生成する。
フレームワーク間の関係性やW3C DTCG仕様の詳細が必要な場合に参照 → references/thinking-frameworks.md
tokens.json — W3C DTCG準拠のDesign Tokensファイルfoundation-spec.md — Foundation定義書目的: Atomic Design階層でコンポーネント体系を構築する。
| 階層 | 定義 | 具体例 |
|---|---|---|
| Atoms | 最小UI要素 | Button, Input, Icon, Badge |
| Molecules | Atomsの組み合わせ | SearchBar, FormField, NavItem |
| Organisms | Moleculesの複合体 | Header, Sidebar, DataTable |
| Templates | ページ構造 | DashboardLayout, AuthLayout |
| Pages | 実コンテンツを含む完成形 | DashboardPage, LoginPage |
各コンポーネントに以下を定義する:
コンポーネントの完成度を軸ごとに管理:
| 軸 | チェック項目 |
|---|---|
| デザイン | Figmaコンポーネント作成、バリアント定義 |
| コード | 実装完了、ユニットテスト通過 |
| ドキュメント | 使用ガイドライン、Do/Don't |
| アクセシビリティ | WAI-ARIA準拠、キーボード操作対応 |
| レビュー | デザインレビュー、コードレビュー完了 |
component-spec.md — コンポーネント仕様書目的: デザインシステムを組織に段階的に展開する。
| ステージ | 基準 | 対象 |
|---|---|---|
| Alpha | 方針実証、フィードバック収集 | 1チームのみ |
| Beta | プロダクション利用可能な品質 | 早期採用チーム |
| GA | 全機能が安定 | 全チーム |
migration-plan.md — 移行計画書(優先順位、互換レイヤ、deprecate期限)adoption-metrics.json — 採用率KPI(採用率、一貫性違反、例外申請数、修正リードタイムを含む)目的: デザインシステムを継続的に維持・改善する。
| モデル | 特徴 | 適する組織 |
|---|---|---|
| 中央集権型 | 専任チームが全管理 | 小〜中規模 |
| フェデレーテッド型 | 専任+各チームがコントリビューション | 中〜大規模 |
| コミュニティ駆動型 | オープンな協調管理 | 大規模・OSS |
| KPI | 説明 | 目標例 |
|---|---|---|
| 採用率 | DSコンポーネント利用率 | >80% |
| 一貫性違反件数 | DSから逸脱したUI数 | 月次減少 |
| 例外申請数 | DS外コンポーネントの例外申請 | <5件/月 |
| 修正リードタイム | バグ報告→修正の平均時間 | <5営業日 |
コントリビューションフロー・バージョニング・監査の設計が必要な場合に参照 → references/governance.md
| スキル | 連携タイミング |
|---|---|
| web-app-designer | DSの成果物(原則・トークン・コンポーネント仕様)を入力として個別画面を設計する |
| mobile-app-designer | モバイル固有のDS拡張(タッチターゲット、プラットフォーム適応)を設計する |
| spec-gen | DS構築後、実装仕様書を生成する |
| architecture-reviewer | DSのアーキテクチャをレビューする |
npx claudepluginhub caphtech/claude-marketplace --plugin design-pluginBuild or audit a design system: component library, design tokens, naming conventions, contribution model, documentation. Use when teams are inconsistent across products.
Aligns designs with existing systems or builds new ones via inventory, token architecture, component specs, naming conventions, accessibility checks, and consistency audits.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.