菜单
Use when a UI is functionally complete but feels generic or unfinished — needs polish before shipping. Covers superchargeable defaults, accent borders, decorated backgrounds, empty-state-as-onboarding, fewer borders, and breaking out of conventional component shapes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when defining a color palette, picking shades, fixing washed-out colors, choosing greys, hitting accessibility contrast, or coloring data visualizations. Covers HSL over hex, palette breadth (~10 colors × 5–10 shades), defining shades upfront, hue-rotation tricks for brightness, warm/cool greys, accessible contrast, and not relying on color alone.
Use when adding shadows, working out elevation, making elements feel raised or inset, designing flat UIs with subtle depth, or layering components for visual interest. Covers light-from-above, shadow elevation systems, two-part shadows (direct + ambient), depth in flat designs via lightness, and overlapping elements to create layers.
Use when a UI feels noisy, when nothing stands out, when buttons/nav/sections all compete for attention, or when you need to decide which element is primary vs secondary vs tertiary. Covers emphasis through weight and color (not just size), the grey-on-color trap, de-emphasizing competitors, label minimization, weight/contrast counterbalance, and action hierarchy.
Use when working with photos, icons, screenshots, or user-uploaded images. Covers picking quality photography, getting consistent text contrast over hero images, respecting an image's intended size (don't scale icons up, don't scale screenshots down), and defending layouts against unpredictable user-uploaded content.
Use when a layout feels cramped or arbitrary, when whitespace is being added by guesswork, when grids are forcing awkward sizes, when content groups feel ambiguous (which label belongs to which input), or when every screen size needs different magic numbers. Covers spacing scales, max-widths, grid escape hatches, mobile-first sizing, and the "more around than within" rule.
Use when starting a new UI, page, screen, or feature from scratch — design real features before chrome, work in low fidelity, ship the smallest version, pick a deliberate personality, and design from constrained systems instead of an open palette.
| name | finishing-touches |
| description | Use when a UI is functionally complete but feels generic or unfinished — needs polish before shipping. Covers superchargeable defaults, accent borders, decorated backgrounds, empty-state-as-onboarding, fewer borders, and breaking out of conventional component shapes. |
Polish doesn't usually require new elements — it comes from amplifying what's already there. Replace defaults with deliberate alternatives, add small chromatic accents, and don't accept the standard shape of a component as the only option.
1. Supercharge defaults. Most "default" UI elements have boring built-in styling that you can replace with something more deliberate:
These are tiny investments that signal craft.
2. Add color with accent borders. A short colored stripe is the cheapest way to make a layout look "designed." Places it works:
The accent doesn't need to be a full border or a complex graphic — a 2–4px stripe in a brand color is enough.
3. Decorate backgrounds, not just elements. Even a polished UI can feel monotonous if every section has the same flat background. Break up sections by:
The rule: keep contrast low so the decoration doesn't fight the content.
4. Treat empty states as onboarding, not error messages. When a user opens a feature for the first time, the empty state is the first thing they see. Don't waste it on "No contacts found." Use the space to:
A great empty state turns "I have nothing to do here" into "Here's how to get started."
5. Use fewer borders. Borders are the default way to separate things, but they make designs busy fast. Better alternatives:
If you already have two of these (e.g. a background change and a border), drop the border.
6. Think outside the component shape. Every component has a default mental model. Push past it:
Constraints help most of the time. Sometimes a component just needs freedom.
Heuristics distilled from Refactoring UI by Adam Wathan & Steve Schoger (https://refactoringui.com). Independent skill package; not affiliated with or endorsed by the authors.
