Master Design

Master Design

Create interfaces that are coherent, specific, usable, accessible, technically sound, and proven in the product people actually use. Treat visual quality and behavioral quality as one discipline.

This skill synthesizes a broad interface-design library without disabling or replacing the source skills. Read source-map.md only when auditing this synthesis, updating the master skill, or explaining its provenance.

Non-negotiable hierarchy

Resolve conflicts in this order:

1. Follow the user's explicit brief, constraints, and approved acceptance target.
2. Protect accessibility, truthfulness, safety, privacy, and user data.
3. Follow the platform's interaction conventions and native semantics.
4. Preserve the project's established design system, stack, brand, and density when they remain fit for purpose.
5. Make task hierarchy, real content, and product state legible.
6. Apply stylistic taste and novelty.

Never let a style heuristic overrule a higher item. A brutalist, minimal, editorial, playful, luxury, or hardware direction is a route, not a universal rule.

Choose the operating mode

Infer one mode from the request and state it briefly when useful.

If the request combines modes, use this order: frame → direct → build → polish → ship. For an existing approved direction, skip direct. For a review-only request, do not mutate source or external state.

1. Establish the truth before designing

1. Read repository and platform guidance completely: AGENTS.md, CLAUDE.md, CONTRIBUTING.md, design-system docs, ADRs, token files, Storybook, and release instructions.
2. Inventory the actual stack, components, tokens, fonts, icons, assets, supported sizes, localization, themes, and preview/test commands.
3. Inventory the product surfaces and states: entry points, windows/routes, subnavigation, overlays, menus, loading, empty, error, disabled, selected, success, destructive, narrow, large, zoomed, and restored states.
4. Determine whether each supplied image is an acceptance target, brand source, content source, or inspiration only. If ambiguity would materially change the work, ask once. Do not blend conflicting references silently.
5. Use real product content and state. Find hard-coded personal names, demo data, stale version text, fake readiness, placeholders, and copy that claims more than the implementation proves.

For existing products, preserve the architecture and interaction model unless the user explicitly authorizes a rewrite. Redesign the system, not just the most visible screenshot.

Read product-and-flow.md for product framing, cognitive load, AI behavior, trust, copy, and failure recovery.

2. Form a coherent direction

Define one sentence for each:

• Audience: who uses this and what they already understand.
• Job: the single primary outcome of the surface or flow.
• Tone: a specific character such as restrained technical, warm editorial, precise utilitarian, refined hardware, or expressive cultural. Never use “clean and modern” as the whole direction.
• Hierarchy: what earns first, second, and third attention.
• Signature: one or two memorable moves that belong to this product.

When direction is genuinely open, show 2–3 distinct systems, not color variations. For each, specify structure, typography, palette/material, interaction character, strengths, risks, and fit. Recommend one based on the audience and job.

When an acceptance target exists, measure it. Reconstruct its structure, proportions, alignment, typography roles, density, and component geometry before adding decoration. Preserve its design DNA without copying unrelated content or accidental defects.

Read style-routing.md for selecting and reconciling aesthetics, brand, anti-slop rules, and reference-based work.

3. Build the design system before the pages

Define or normalize these shared primitives before leaf-screen polish:

• semantic color roles and contrast pairs;
• typography roles, line heights, measures, and numeric styles;
• spacing scale and layout margins;
• radii, borders, elevation, material, and lighting direction;
• icon family, stroke/fill weight, optical size, and decorative semantics;
• control heights, horizontal padding, label baselines, focus treatment, and state behavior;
• motion durations, easing, reduced-motion behavior, and interruption rules;
• window/container size policies and responsive breakpoints based on content.

Peer actions that are intended to read as a set must share height, radius, vertical padding, baseline, and state geometry. Use equal width when the actions have equal rank; use content width deliberately when rank or available space differs. Check optical centering, not only numeric constraints.

Never solve a repeated defect in one screen when its cause is a token or shared component. Audit every consumer after changing a primitive.

Read system-and-craft.md for component geometry, layout, typography, color, surfaces, icons, motion, and accessibility details.