design

name	design
description	Produces distinctive, production-grade UI for any component, page, or visual interface. Handles screenshot-driven iteration when the user sends an image with a visual complaint. Not for backend logic or data pipelines.
when_to_use	build page, create component, make it look good, style, design, screenshot with visual complaint, frontend ui
metadata	{"version":"1.1.0"}

Design: Production-Grade Frontend UI

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.

Screenshot Iteration Mode

Activate when the user sends a screenshot or image alongside a complaint ("这里很丑", "这个不对", "fix this", "looks wrong"). The existing product is the direction. Skip the five-question direction lock.

Flow:

1. Read the screenshot. State the problem in one sentence: what specifically looks wrong (spacing, contrast, alignment, typeface, color).
2. Wait for the user to confirm the diagnosis before touching code.
3. If the diagnosis is a known UX problem (split-view sync, infinite scroll, virtualised list, sticky header), spend one round surveying how 2-3 mature products in the same category solve it before writing code. Cite what each does. Skip only if the fix is purely cosmetic (color, spacing, copy).
4. Find the responsible code: grep for the component name or class, read the actual file. Do not rely on memory or assumptions about file location.
5. Apply the minimal fix. One component, one issue.
6. Ask the user to verify in the browser. Do not hand off without this step.

Boundary: if the fix requires changing 3 or more components, or if it reveals a direction problem rather than a specific bug, pause and run the full direction lock before continuing.

Lock the Direction First

Before writing any code, ask the user directly, using the environment's native question or approval mechanism if it has one:

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 / Gemini.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 when the reference is a well-known brand (Linear, Stripe, Gemini, Vercel, Apple, Tesla, Notion, Figma, Airbnb, Spotify, and ~56 others catalogued in awesome-design-md -- see the brand preset section in references/design-reference.md): ask the user whether to pull the curated preset via npx getdesign@latest add <brand>. If they approve, run it, read the generated DESIGN.md at project root, then do the 3-property decomposition against that file rather than from memory. The preset is a starting point, not a direction -- the user still names the aesthetic precisely, and this skill's reflex-font blocklist and absolute bans still win on any conflict.

3. What is the one thing this leaves in memory? A typeface, color system, unexpected motion, asymmetric layout. Pick one and make it obvious.

4. What are the hard constraints? Framework, bundle size, contrast minimums, keyboard accessibility.

5. 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 proceed until all five are answered.

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.

Only attach the target component folder or package. Exclude .git, node_modules, dist, and lock files. Dragging in an entire monorepo pollutes the context with irrelevant code and degrades output quality.

App shell exception (sidebar + main workspace)

When the answer to question 1 is an app shell (Slack, Linear, Notion class):

• Decorative backgrounds default to off
• Surface hierarchy uses background-color steps and shadow only
• All interactive elements get active:scale-95
• Button radius is consistent within each component type (pick one: pill, square, or one fixed value -- do not mix)
• Commit to a named radius scale before the first component (see Border radius system in references/design-reference.md)

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.

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: 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.

Non-Negotiable Constraints

references/design-reference.md is already loaded during direction lock. It owns the full rules: typography, OKLCH color, motion timings, layout defaults, CSS-pattern bans, accessibility baseline, and complexity matching. Apply them. Do not restate them here.

Mid-Build Checkpoint

After every third component or one complete page section (whichever comes first), stop and check:

1. Re-read the visual thesis (mood, material, energy) stated during direction lock.
2. Ask: does what is on screen right now match that thesis, or has it drifted toward a generic default?
3. If drifted: identify the specific element that broke first (typeface, color choice, card treatment, spacing) and fix it before continuing.

Do not wait until handoff to run the AI Slop Test. Catching drift early costs one component; catching it at handoff costs the entire build.

When Asked For Options

Give at least 3 variations, spread across genuinely different dimensions:

• Dimensions to vary: visual density, typographic personality, color temperature, layout structure, motion character, amount of decoration, level of abstraction
• Mix approaches: one option that follows existing conventions closely, one that remixes the brand DNA in a new way, one that is deliberately unexpected
• Progress from basic to bold: the first option is safe and understandable; later options push further
• Three options that differ only by accent color are not three variations. Vary the layout, the typeface, the motion, the surface treatment.

Gotchas

What happened	Rule
Used Inter as the display font	It communicates nothing. Pick something with a personality.
Three cards, identical shadows, identical padding -- a template	If swapping content doesn't require layout changes, redo it.
Claimed it looked right without opening a browser	Code correct in your head can look broken in the browser. Open it.
Chose glassmorphism, ignored the mobile constraint	backdrop-filter is expensive on low-power devices. Name the tradeoff.
Colors that "go with everything" go with nothing	Commit to a dominant color plus one sharp accent.
State transitions jittered because element sizes changed per state	All states must occupy the same layout footprint; use min-height or fixed dimensions.
Brand disappeared when the nav was hidden	Brand test: if the first viewport could belong to another brand after removing the nav, the branding is too weak.
Copy-heavy hero that nobody reads	If deleting 30% of the copy improves the page, keep deleting. Each section gets one job: explain, prove, deepen, or convert.
Dashboard built like a marketing page	App/dashboard surfaces need utility copy and a working surface first. No hero section by default.
Every project ended up with the same look	Vary light/dark, serif/sans, dense/spacious. If it could have been the last project, it is not designed for this one.
Heavy border: 1px solid on every container, flat buttons, no depth	This is 2015 UI kit default. Replace with shadow-step depth, active:scale-95 on buttons, translucent borders (border/30).
Light-mode app: white panel on white background, visually indistinguishable	Adjacent nested surfaces must differ visually. Either background step (sidebar vs main ≥4% lightness difference) or shadow minimum 0 1px 3px rgba(0,0,0,0.10).
Added an extra section because it "felt incomplete"	Ask first. The user knows their audience; you do not. If you think more content would help, surface the suggestion as a question, do not ship it unilaterally.
Tried to generate a logo, app icon, or brand illustration	Icons, naming, and brand identity require human taste and judgment. Use a labeled placeholder and ask the user to supply the real asset.
Moved tab bar / sidebar to a new edge, neighbours overlapped or resized awkwardly	Repositioning a chrome element changes the bounding box of every neighbour. After the move, re-measure the safe area against window controls (traffic lights on macOS), title, and any floating overlays. Verify at narrowest supported width.

Handoff

Run these litmus checks before writing the handoff summary:

• Is the brand or product unmistakable in the first screen?
• Is there one strong visual anchor (real imagery, not a decorative gradient)?
• Can the page be understood by scanning headlines only?
• Does each section have one job?
• Are cards actually necessary, or just default styling?
• Does motion improve hierarchy or atmosphere, or is it ornamental?
• Would the design still feel premium if all decorative shadows were removed?
• AI Slop Test: scan the first screen for default patterns that scream "AI made this." Examples (not exhaustive): reflex font (Inter, DM Sans, Outfit...), purple-to-blue gradient, centered hero with two CTAs side by side, three identical cards, top nav logo-left-links-center-action-right, decorative gradient with no real imagery. If any appear unintentionally, the direction is not committed enough. Fix typography, color, or layout until none remain.

If any check fails, fix it first. Then revisit the common traps list from references/design-reference.md (already loaded during direction lock; do not re-read the file). Then ask the user to open the result in a browser and confirm it looks right at full width. Also check at 375px width: resize the browser or use DevTools device emulation. If the layout breaks, content overflows, or text is unreadable at mobile width, fix it before handing off. Do not hand off until both checks pass.

End with:

• 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

After handoff, stop. Do not iterate unless the user requests changes.

Print Typography Mode

Activate when: resume, white paper, one-pager, PDF, print, spacing, typography, or styled HTML document

Lock three constraints first:

1. Target page count (e.g., "one page strict" vs "flexible length")
2. Typography direction: dense editorial (1.1–1.3), reading-focused (1.5+), or hybrid
3. Whitespace hierarchy: which gaps should differ most?

Then measure and suggest:

• Line-height tuning with page-savings math (e.g., "1.8 → 1.45 saves 3 lines per page")
• Padding/margin scale audits (enforce 4px–12px–16px bands, no random 7px)
• Em-dash → en-dash substitution (optical weight reduction)
• Font rendering diagnostics (synthetic bold detection, fallback chains)

Output: specific CSS changes with before/after line counts.