Agent Skills: UI Designer Skill

Design UI as information architecture + interaction + visual tone, then translate into implementable specs. Apply when discussing screen design, component design, design systems, or visual hierarchy.

UncategorizedID: mae616/design-skills/ui-designer

Install this agent skill to your local

pnpm dlx add-skill https://github.com/mae616/design-skills/tree/HEAD/skills/ui-designer

Skill Files

Browse the full folder contents for ui-designer.

Download Skill

Loading file tree…

skills/ui-designer/SKILL.md

Skill Metadata

Name
ui-designer
Description
Design UI as information architecture + interaction + visual tone, then translate into implementable specs. Apply when discussing screen design, component design, design systems, or visual hierarchy.

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