Produces distinctive production UI and screenshot-grounded visual polish. Use when building or restyling pages, components, or typography. Not for backend logic or data pipelines.
1---2name: ui3description: Produces distinctive production UI and screenshot-grounded visual polish. Use when building or restyling…4---56# plugins/waza/skills/ui/SKILL.md
U
SKILL.mdAgent skill
Transport
File
Status
Listed
SKILL.md
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
shterminal
1npx skills add tw93/Waza --skill ui -a cursor -y
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
Download plugins/waza/skills/ui/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does ui live?
The publisher keeps it at https://github.com/tw93/Waza.
Which agents can use ui?
Claude, Cursor, Codex, and Grok Build can read a SKILL.md you add from the publisher's repository. Grok Bot installs it when you send the skill's GitHub folder link in a chat.
From the publisher
SKILL.md
name
ui
description
Produces distinctive production UI and screenshot-grounded visual polish. Use when building or restyling pages, components, or typography. Not for backend logic or data pipelines.
when_to_use
做组件, 不好看, 不和谐, 不清晰, 很丑, 很怪, 很傻, 突兀, 不协调, 字体, 排版, UI, 截图, build page, create component, make it look good, screenshot with visual complaint, font looks wrong
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.
For UI copy cuts, load the UI copy rules in references/design-reference.md before proposing deletions, including in quick-fix and screenshot modes.
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 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; 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)
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.
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.
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 depth treatment (shadow vs background step vs border), and accent color family. Name those instead.
Shortcut for well-known brands: when exact brand tokens would materially improve a direction that remains underdetermined, offer the "Reference-site Brand Presets" path in references/design-reference.md. Run the preset only with explicit approval, then decompose against the generated file. Skip it when screenshots, source tokens, or sibling components already settle the direction.
What is the design signature? A typeface, color system, unexpected motion, asymmetric layout. Pick one and make it obvious.
What are the hard constraints? Framework, bundle size, contrast minimums, keyboard accessibility.
What is the signature micro-interaction? Scale on press, staggered reveal, or contextual icon animation. Pick one and know exactly how it's implemented.
Do not write code until all five are resolved by evidence, a stated assumption, or clarification. A dimension can be "none": a quiet utility surface may deliberately have no signature motion.
Survey 2-3 mature products only when the problem is a genuinely unfamiliar interaction pattern or the direction remains underdetermined after reading the current product. Record one concrete decision from each. Skip this for cosmetic fixes, established sibling components, and tasks whose references already settle the pattern; mandatory benchmarking on every component produces imitation and delays obvious work.
Source repo as reference
When the user provides a repository URL or pastes source code of an existing product to recreate or extend: the file tree is a menu, not the meal. Do not reconstruct the UI from memory or training data. Instead, read the actual source:
Theme and token files: theme.ts, colors.ts, tokens.css, _variables.scss, or equivalent
Global stylesheets and layout scaffolds
The specific components the user mentioned
Lift exact values: hex codes, spacing scale entries, font stacks, border radii. A rough approximation is not pixel fidelity. Read only the target component folder or package, never .git, node_modules, dist, or lock files.
Existing-native-app exception (do not propose wholesale platform restyling)
When the target is an existing macOS / iOS / Android native app that already has a coherent visual direction, do not propose a wholesale port to a newer platform style (macOS 26 Liquid Glass, iOS 18 frosted material, Material You, Fluent Design, etc.) as the default improvement plan. Wholesale restyling reads as "I do not have a specific design intent, here is the platform's." Default to incremental polish on the existing direction: spacing, alignment, hover and focus states, typography hierarchy, copy tightening, motion timing. Only propose a platform-style migration when the user has explicitly asked for it in this turn, or when the existing direction is broken in a way that incremental polish cannot fix. State the existing direction in one sentence before proposing changes so the user can correct the read.
When the change touches motion, press states, or animation timing on that native surface, load references/design-native-motion.md: the judgment carries over from the web rules, the idioms and the platform's default curves do not.
App shell exception (sidebar + main workspace)
If question 1 is an app shell (Slack, Linear, Notion class), load the "App shell rules" section in references/design-reference.md and apply those constraints before proceeding.
Data dashboard exception
If the surface is a dashboard, analytics view, or chart-heavy interface, also load references/design-data-viz.md for chart selection, number alignment, and product-benchmark rules. Skip when building marketing pages, landing pages, or generic components.
State the chosen direction in one sentence, then load references/design-reference.md and check the tech stack conflicts table. Name the single CSS strategy before writing the first component. Token decisions (color, font, motion), production craft, aesthetic review, DESIGN.md, options, and strategic omissions all live in that one canonical file.
Summarize the direction as three lines before writing any code:
Visual thesis: mood, material, and energy in one sentence (e.g. "warm brutalist editorial with high-contrast ink type and rough paper texture")
Content plan: hero -> support -> detail -> final CTA, one line each. For app/dashboard surfaces: skip the marketing structure, default to utility mode (orient, show status, enable action), no hero unless explicitly requested.
Interaction thesis: either none with one evidence-based reason, or 2-3 specific motion ideas that change how the page feels (e.g. "hero text slides in on load, section headers pin while content scrolls beneath, CTA pulses on hover")
For production or multi-page UIs, expand the thesis into the 9-section DESIGN.md scaffold in references/design-reference.md (theme, palette, typography, components, layout, depth, do/don't, responsive, prompt guide). For a single component, the three lines are sufficient.
When Asked For Options
Give at least 3 variations across genuinely different dimensions; the Options Guide in references/design-reference.md names the dimensions, the mix, and the basic-to-bold progression.
Offer without being asked when the decision is taste, not correctness: icon, weight, accent, motion feel. Two labeled candidates beat one landed guess, because the reply is a single letter instead of a rewrite round. For a structural change, describe the end state in a sentence or two and get a nod before writing the code.
Hard Rules
Always-on bans for every mode, each with its rewrite in the Absolute Bans table of references/design-reference.md: no thick side-border accents, gradient text, default glass cards, reflex purple-to-blue/cyan-on-dark palettes, generic rounded shadow-card grids, modal escapes for ordinary overflow, transition: all, or layout-property animation.
Two motion rules apply in every mode, including the ones that skip the full reference. Frequency decides whether something animates at all: nothing keyboard-initiated animates, and anything the user triggers hundreds of times a day reads motion as lag, so it gets none. Every action needs visible acknowledgment: an immediate selected, open, or loading state already counts; add press feedback only when the result leaves a gap. Hover alone cannot acknowledge activation, and feedback need not move the control.
Direction lock loads references/design-reference.md for the full rewrites, typography, OKLCH color, motion timings, layout defaults, accessibility baseline, and complexity matching. Screenshot and quick-fix paths use the compact bans above instead of paying for that full reference. These rules keep output off the generic default, not to run as a lint pass: when the committed direction genuinely calls for breaking one, break it deliberately and name the tradeoff in the handoff. The accessibility baseline and CSS-pattern bans stay non-negotiable.
Gotchas
What happened
Rule
Relied on … truncation to fit text in a fixed-width slot
Guarantee fit instead: compact the format, cap to whole segments, or hard-trim with no glyph. Metric and label footers must never tail-truncate into an ellipsis.
One extra word pushed a line into a wrap; the last line held a single orphan word
Inspect the container and forced breaks first; tighten repetition without losing meaning, never shrink type for a widow. Sweep sibling blocks for the same layout cause, not every short last line.
Five text styles inside one small card
One text style per role inside a card, hierarchy by order; more than three distinct text styles in a small block is the smell.
Output: Aesthetic Review
After significant build phases and at handoff, re-read the visual thesis from direction lock. If what is on screen drifted toward a generic default, identify the specific element that broke first (typeface, color, card treatment, spacing) and fix it before continuing.
Before the handoff summary, a new page or visual system also runs the Aesthetic Review Checks in references/design-reference.md. Every surface runs the AI Slop Test: would a stranger glancing at the first viewport say "an AI made this"? Scan it for the Absolute Bans and Common Traps in references/design-reference.md (reflex font, default gradient, centered hero with two CTAs side by side, three identical cards, generic top nav) and fix typography, color, or layout until any that were not an explicit part of the direction are gone.
If any check fails, fix first. Render the product's supported viewport or window range yourself: web breakpoints on both sides, and native minimum width, minimum height, their combination, and normal size. Test samples do not require new layout branches. Only when the host cannot render, say so and hand the user the exact view to check.
For a new page or visual system, end with (other paths use their mode's closing):
Aesthetic direction, named and justified in 2-3 sentences
Non-obvious choices explained: typeface, color decisions, layout logic
Instructions for replacing placeholder content with real content
