design

# Design: 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 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. Route to Screenshot Iteration Mode, 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. ## Durable Context Preflight See [rules/durable-context.md](../../rules/durable-context.md) for when to read durable context, the read-order budget, and the memory-type mapping. For `/design`, visual constraints are `decision`, `preference`, and `principle` entries; reusable product and UI patterns are `pattern` and `learning`. Current screenshots, rendered output, code, design tokens, and user feedback 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. ## Visual Quick-Fix Mode Activate when the user asks for a narrow visual repair with a concrete symptom: overflow, clipped or wrapped text, misalignment, spacing imbalance, contrast/readability, localized text not fitting, or compact responsive breakage. This is for fixing an existing surface, not redesigning it. Flow: 1. Read the current UI evidence: screenshot, rendered page, native view, or responsible component. 2. Name the exact visual defect in one sentence. 3. Make the smallest material, geometry, spacing, contrast, typography, or text-fit change that fixes that defect. 4. Verify the real running surface or generated artifact. Check long words, localized strings, compact states, and at least one narrow viewport when applicable. 5. If the fix touches three or more components, changes product behavior, or reveals a direction problem, stop and switch to Screenshot