mcpField
U
ui-designer

ui-designer

github.com/mae616デザイン・UI11136 回インストール39 週間前に更新
リポジトリ

ui-designer について

画面、コンポーネント、情報設計、デザインシステムを扱う UI 設計スキルです。ユーザーの目標を優先順位の明確な一貫した仕様にまとめ、状態や実装の詳細も定義します。

主な機能

  1. 01画面の目標と成功基準の定義
  2. 02情報と操作の優先順位付け
  3. 03コンポーネントと状態の仕様化
  4. 04トークンとスタイルの指針作成
  5. 05ローディング・エラー・空状態の網羅
  6. 06実装詳細の明確化

活用シーン

  1. 01画面レイアウトの設計
  2. 02再利用可能な UI コンポーネントの仕様作成
  3. 03情報アーキテクチャの策定
  4. 04実装向けの例外状態の文書化

インストール

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

$npx skills add https://github.com/mae616/design-skills --skill ui-designer

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

README（原文）English

プロジェクトの README より

この README の日本語訳はまだありません。以下は英語の原文です。日本語の紹介はページ上部をご覧ください。

UI Designer Skill

When to Apply

Apply this skill when the request involves:

  • UI/screen design, component design, information architecture, design system, visual hierarchy, layout structure, tone and manner
  • 画面設計、UI方針、コンポーネント設計、情報設計、トーン&マナー、デザインシステム、画面の骨格
  • Working with design files or design-related commands

Core Principles

  • UI is not art, it's decision support. Help users achieve their goals as quickly as possible.
  • Systematize repetition. Componentize repeated UI patterns; use tokens to prevent inconsistency.
  • Specs include states. A complete spec covers loading, error, empty, and disabled states.

Design Philosophy (Decision Rules)

  1. Prioritize first. Decide what users see first vs. what can wait.
  2. Don't cram everything. Use progressive disclosure to reveal information in stages.
  3. Always define states. Normal / loading / empty / error / no-permission must be specified.
  4. Enforce consistency through rules. Components, tokens, spacing, and typography create coherence.
  5. Leave no ambiguity for implementers. Specs should be precise, not vague prose.

Initial Questions to Clarify

  • What is the screen's goal? (What counts as success?)
  • Who is the primary user? (Persona / usage context)
  • What is the primary action?
  • What are the edge cases? (Empty / error / permission / slow network)
  • What is the reuse scope? (Page-specific or cross-cutting?)

Output Format (Follow This Order)

  1. Screen purpose / success criteria
  2. Information architecture (priority, structure)
  3. Component proposal (responsibility, props, states)
  4. Token / style guidelines (colors, spacing, typography)
  5. Edge state specs (empty / error / loading)
  6. Next actions (prototype → implementation)

Common Pitfalls

  • Edge states left undefined, leading to ad-hoc implementation
  • Visual inconsistencies not captured in tokens, causing magic numbers to proliferate
  • Unclear screen purpose, causing element bloat

コメント

Markdown 対応