gpui-kit-design-guides
PopularThe normative Design Guides for GPUI Kit desktop applications. Read in full before designing or changing any screen, layout, spacing, visual hierarchy, color, density, component choice, interaction state, overlay, motion, data-heavy view, or interface copy in a GPUI Kit (gpui-kit / gpui-component) application, and before reviewing UI work for design quality. Also use when asked what the design rules are, or whether a UI decision follows them.
Related Skills
The normative Design Guides for GPUI Kit desktop applications. Read in full before designing or changing any screen, layout, spacing, visual hierarchy, color, density, component choice, interaction state, overlay, motion, data-heavy view, or interface copy in a GPUI Kit (gpui-kit / gpui-component) application, and before reviewing UI work for design quality. Also use when asked what the design rules are, or whether a UI decision follows them.
GPUI Kit Design Guides
The guide is references/design-guides.md. It is
a requirement, not inspiration. Read the guide file itself before doing UI
work. Do not answer from this page, from an existing screen in the codebase, or
from training data.
If the file is missing, fetch https://gpui-kit.com/docs/design-guides.md.
The guide is a verbatim copy of that page, so its link to ./coding-guides.md
means the Coding Guides in the gpui-kit skill (or https://gpui-kit.com/docs/coding-guides.md).
How to read it
Read the whole guide for a new screen or a redesign. For a narrow change, read
"Design thesis" and "Start from the task" first, then the section for the
change. Sections, in order (grep -n '^## ' references/design-guides.md):
| Section | Read when |
|---|---|
| Design thesis | Always |
| Learning from Shadcn | Choosing what to borrow from web component libraries |
| Start from the task | Always; task hierarchy, interaction promise, what to leave out |
| Visual language | Color, typography, spacing, radius, borders, elevation, density, icons |
| Layout patterns | Window structure, sidebars, toolbars, panels, forms, resizable regions |
| Components and composition | Picking a component, composing parts, when to build a new one |
| Interaction states | Hover, focus, pressed, selected, disabled, loading, validation, danger |
| Feedback and overlays | Dialog, sheet, popover, menu, notification, tooltip, dismissal, focus |
| Motion | Any animation or transition |
| Designing data-heavy interfaces | Tables, lists, trees, dashboards, dense inspectors |
| Interface language | Any user-facing text: labels, buttons, titles, errors, empty states |
| Internationalization and platform fit | Multi-locale copy, Chinese terminology, macOS/Windows conventions |
| Guidance for AI-generated interfaces | Always when an agent produces UI |
| Accessibility checklist | Before finishing |
| Design review checklist | Before finishing; run every item against the work |
Non-negotiables
A floor, not a substitute for the guide.
- Desktop before web convention. Keyboard access, window chrome, menus,
dense data views, resizable regions, persistent navigation. ButtonvsLink.Buttonfor every in-app command,ghostor
outlinewhen it should read quietly.Linkonly for external URLs and
email addresses.- Tokens before values. No raw hex or
rgb(...); usecx.theme()
semantic tokens and rem-based helpers. Any spacing number quoted in the guide
is the current default scale, not a literal to repeat. - State must be visible. Hover, focus, selection, disabled, loading,
validation, and destructive states each need distinct, consistent treatment. - Overlays. Escape dismisses the topmost surface and returns focus to its
trigger. - Copy. Name the object and the verb:
Delete "Roadmap"?with aDelete
button, notAre you sure?withOK.
Finish by running the Design review checklist against the work.
