/ui

name: ui
description: "Produces distinctive, production-grade UI for pages, components, visual interfaces, typography, and screenshot-driven polish. Use when users ask in any language for UI, page, component, frontend, typography, screenshot-grounded visual polish, or complaints that a screen looks unclear, ugly, inconsistent, or visually wrong. Not for backend logic or data pipelines."
when_to_use: "设计, 做页面, 做组件, 不好看, 不和谐, 不清晰, 很丑, 很怪, 很傻, 突兀, 不协调, 字体, 字形, 排印, 排版, 样式, 前端, UI, 截图, build page, create component, make it look good, style, design, screenshot with visual complaint, typography, font looks wrong"
dispatch_intent: "UI, component, page, visual interface, frontend, artifact-grounded screenshot aesthetic complaint"

UI: Build It With a Point of View

Prefix your first line with 🥷 inline, not as its own paragraph.

If it could have been generated by a default prompt, it is not good enough.

Outcome Contract

• Outcome: a usable interface or visual fix with a clear point of view and no incoherent layout, text, or responsive breakage.
• Done when: the real rendered surface or generated artifact has been checked against the user's visual goal and the relevant viewport states.
• Evidence: screenshots, rendered UI, source components, design tokens, accessibility constraints, and user-provided references.
• Output: the implemented visual change or a precise visual review with the remaining verification gap named.

**Output language rule:** Never use U+2014 em dash in any output from this skill. Use commas, colons, or periods instead.

**Chinese gut-feel complaints**: when the user says "很傻", "很怪", "突兀", "不协调", "不和谐" about a visual, treat it as an aesthetic rejection, not a debugging symptom. Generated image assets stay in `references/mode-generated-asset.md` even when the complaint arrives with a screenshot; coded or rendered UI surfaces route to `references/mode-screenshot-iteration.md`, not to `/hunt`.

**Document and print typography routes out.** When the deliverable is a shippable document rather than a product UI surface (report, slide deck, resume, long-form or print-oriented page, paged PDF), do not hand-roll an over-designed document layout here. Hand it to a document typesetting skill if one is installed and let that skill draft the detailed plan. Screen 排版 (app surfaces, components, web pages) stays in this skill.

Durable Context Preflight

See [references/durable-context.md](references/durable-context.md) for when durable context is in scope and the redaction gate that applies before any of it becomes a durable rule.

For `/ui`: current screenshots and rendered output override memory. Reuse durable visual preferences and mature interaction patterns, but still name the current visual problem from the screenshot or source before changing code.

Mode Picker

Pick the path that matches each deliverable, then read it in full. A request may combine paths, such as a page plus its generated social card. All matching paths share one initial preflight clarification round across the request; event-triggered recovery after work begins may reopen only the affected fields. When triggers overlap, route by the artifact being changed: generated image assets take precedence over screenshot evidence for that asset, while screenshot iteration handles coded or rendered UI surfaces. Building a new surface is the default and starts at [Lock the Direction First](#lock-the-direction-first); it needs neither mode file.

| Ask | Path | |---|---| | Bounded fix to an existing screen ("this looks cramped", "the spacing is off") | load `references/mode-quick-fix.md` | | Screenshot supplied as the evidence to improve against | load `references/mode-screenshot-iteration.md` | | Generated image asset (diagram, cover, social card, illustration) | load `references/mode-generated-asset.md` | | New page, component, or visual system | [Lock the Direction First](#lock-the-direction-first) |

Lock the Direction First

**Adding a surface to a mature product skips direction lock in the other direction**: when the task is a new panel, dialog, sheet, toast, or confirmation inside an app that already has same-class components, the direction is the app. Grep for the existing sibling component first and reuse its container, motion, and typography tokens; inventing a new style needs a stated reason why no existing component fits. First drafts that ignore the app's own component vocabulary get rejected on sight.

Resolve the five direction dimensions below before writing code. Take colour, type, width, and voice from the current product's tokens, sibling components, screenshots, and the repo's git history first; then from other shipped products by the same team or author when they exist; then from the conversation. Model-default palettes, default fonts, and freehand graphics are allowed only when no reference exists. Infer first. Across every path in the request, ask in one compact clarification round with at most two sub-questions, only when the missing answer would materially change a deliverable. State the strongest inferred answer for every unresolved dimension and ask the user to correct only the material assumptions. An omitted answer accepts the stated assumption. A contradictory answer reopens only the affected dimension and must be resolved before that deliverable proceeds. An existing product may answer all five without another user turn.

1. **Who uses this, and in what context?** Analyst dashboard differs from landing page or onboarding flow. See "App shell exception" below if the answer is a sidebar + main workspace layout. 2. **What is the aesthetic direction?** Name it precisely: dense editorial, raw terminal, ink-on-paper, brutalist grid, warm analog. "Clean and modern" is not a direction. If the user names a reference site or product ("feels like Linear / Claude.ai / Vercel"), do not accept it as a direction -- extract 3 concrete properties from it: button radius philosophy, surface de