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 & print typography → Kami. 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. Suggest the user run it through Kami (tw93/Kami), a document design system with a fixed constraint language and templates, and let Kami draft the detailed plan. Screen 排版 (app surfaces, components, web pages) stays in this skill.