/design-screen

name: design-screen
description: Design or build a page, screen, landing page, website, app or UI from a request - the whole job, end to end. Use this for "design a landing page", "build a settings screen", "make me a website", "design the onboarding", "ออกแบบหน้าเว็บ", "ทำหน้า landing", "ออกแบบ UI", "ทำแอป". It runs the pipeline no single skill covers: the house doctrine, a written Brief Inference so the result is not the statistical mean, a committed visual direction, tokens, build, the objective gates, then an adversarial critic. Hands off to data-dashboard for dense data screens, redesign for existing UI, and image-to-code when a reference image is given.

Skill: Design a screen

Do this first, before anything else

**Write the Brief Inference block into your reply now.** Not after reading the rest of this file, not in your head, not "once the layout is clearer" - now, before any markup, any file, any tool call.

Domain:           fintech | editorial | dev-tool | healthcare | consumer | ...
Audience & tone:  expert vs first-time, calm vs energetic, premium vs utilitarian
Mood:             the one adjective the result must earn - "expensive", "precise", "warm", "brutal"
Motion depth:     none | subtle feedback | expressive choreography
Layout family:    the section sequence you will use, named, varied per section
Reference anchor: an archetype, or a named system - see step 3

Fill in every line with a decision. `Mood: clean` is not a decision; `Mood: expensive` is. If you cannot name the mood and the layout family, you have not decided anything yet and whatever you generate will regress to the mean.

**The stop condition:** if you are about to write markup, create a file, or call a tool that produces UI, and this block is not already in your reply, stop and write it first. Measured on 2026-10-07, one run in three skipped it - the skill loaded, the block did not get written, and the result was a screen designed by nobody. This section is at the top of the file because it was previously below twenty-nine lines of background, and background is not an instruction.

Everything below is how to execute the decisions above.

---

> **Is the kit here?** This skill reads files from the kit. Check once: > `ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING` > On `KIT_MISSING` only the skill folders were installed, which is what > `npx skills add` does. Say so plainly, point the user at > `npx ux-ui-agent-skills init` or the plugin install, and stop. Do not guess the > contents of a file you could not open.

Hand off instead, when the work is actually

| The request | Use | |---|---| | A dashboard, terminal, console, or any screen whose job is many numbers at once | `data-dashboard` | | An existing site or app to improve | `redesign` | | A screenshot, mockup or reference image to match | `image-to-code` | | One component's spec, not a screen | `design-component` | | A brand foundation from scratch, before any screen | `brandkit` |

Otherwise, continue.

---

1. Taste preflight

The block at the top of this file. If it is not in your reply yet, go back and write it before reading further - the rest of this skill executes decisions it assumes you have already made.

Full version and the reasoning: `${CLAUDE_SKILL_DIR}/../../../taste/design-taste.md`.

Banned defaults — break each one deliberately

These are the tells that make UI read as generated. They are defects, not starting points.

• **Three or four identical equal-weight cards.** One thing leads: more size,

more weight, or its own row. A grid of equals gives the eye nowhere to land.

• **Everything centered.** Use asymmetry and a real grid. Center sparingly.
• **The same left-text / right-image row repeated.** Vary composition per section.
• **Display type that is just bold body text.** The largest heading is at least

2.5x the body size, short, on a wide measure (18-24ch).

• **Generic drop shadow on every box.** Most things are flat; elevation is layered

and rare.

• **Pure `#000` on `#fff`.** Off-black on warm-white, from the theme.
• **A rainbow of accents.** One primary, one accent at most; neutrals carry it.
• **Emoji anywhere** - icons, bullets, status dots, labels. Use lucide inline SVG

with `currentColor`, or plain words. This is a hard gate, not a preference.

• **Em-dashes in UI copy**, marketing filler ("elevate", "seamless", "unlock"),

hollow triads ("powerful, intuitive, beautiful"), fake labels ("SECTION 01", lorem ipsum). Say the concrete thing or say nothing.

• **A colored border on one side only** of a card, alert, toast or callout. The

tinted 3-4px strip is a generated-UI cliche. Full hairline border or surface separation, and status carried by a real icon plus text, never colour alone.

• **Cramped vertical rhythm.** Generous macro-whitespace between sections.

---

2. Doctrine

Load `design-doctrine` and follow it. The parts that decide this job: token by intent, one shared theme, the eight states on every interactive element, one thing leads, zero emoji, and never state a number you did not measure.

3. Direction into tokens

Pick the reference anchor from `${CLAUDE_SKILL_DIR}/../../../taste/aesthetic-systems.md` or the library at `${CLAUDE_SKILL_DIR}/../../../design-systems/library/`, then resolve it into tokens rather than styling screens directly. One CSS-variable layer, imported once. If a brand colour fails contrast, adjust it: taste serves tier 4 and never overrides accessibility.

Reference output to match for quality: `${CLAUDE_SKILL_DIR}/../../../examples/showcase/` and `${CLAUDE_SKILL_DIR}/../../../examples/templates/`.

4. Build

**Mobile is the base**, not an afterthought: write the phone layout as the base styles and layer wider screens on with `min-width`. `max-width` is fine for a narrow refinement, never as the way mobile gets supported. Every value a token. Every interactive element ships all eight states. Content f