UI/UX Myth

<!-- Merged from: interface-design, ui-ux-implementation, ui-ux-pro-max. Source directories archived 2026-04-01. -->

UI/UX Myth

End-to-end UI/UX design intelligence and implementation. Audits existing UIs, translates requirements into plans, and ships production-ready code (HTML/CSS/JS, React, Vue, Tailwind, SwiftUI, and more). Research-backed, opinionated, anti-template.

ARGUMENTS: $ARGUMENTS

---

Inputs This Skill Accepts

• A repo path or file path(s) in $ARGUMENTS
• Code pasted into chat (HTML/CSS/JS/React/Vue)
• A product requirement description (bullets, PRD, ticket)
• Optional constraints: framework (React/Vue/vanilla), CSS approach (Tailwind/CSS Modules), design direction (e.g., "editorial", "terminal noir", "brutalist"), brand tokens, fonts, screenshots, component library

If requirements are incomplete, ask at most 3–6 high-value questions. Otherwise, state assumptions and proceed.

---

Progressive Disclosure: Reference Files

Load only what's needed for the task:

Analysis & planning:

• references/analysis-patterns.md — Code/UI audit process
• references/requirements-gathering.md — Requirements extraction + clarifying questions
• references/planning-methodology.md — Planning templates + sequencing
• references/implementation-guide.md — Implementation patterns + code scaffolds

Design guidance:

• references/principles.md — Code examples, specific values, dark mode (from interface-design)
• references/design-principles.md — UX principles + citations
• references/typography-guide.md — Typography
• references/color-systems.md — Color systems + theming
• references/accessibility.md — Accessibility patterns
• references/animations.md — Motion/animation
• references/validation.md — Memory management, when to update system.md
• references/critique.md — Post-build craft critique protocol

Framework specifics:

• references/framework-patterns/react.md
• references/framework-patterns/vue.md
• references/framework-patterns/tailwind.md
• references/framework-patterns/vanilla-css.md

Examples:

• references/examples/hero-section.md
• references/examples/navigation.md
• references/examples/card-layouts.md

Database-driven design system (searchable, 67 styles, 96 palettes, 57 font pairings, 99 UX guidelines):

• Scripts: scripts/search.py, scripts/design_system.py, scripts/core.py
• Data: data/ — styles.csv, colors.csv, typography.csv, ux-guidelines.csv, charts.csv, products.csv, landing.csv, stacks/

---

The Problem

You will generate generic output. Your training has seen thousands of dashboards. The patterns are strong.

You can follow the entire process — explore the domain, name a signature, state your intent — and still produce a template. Warm colors on cold structures. Friendly fonts on generic layouts. "Kitchen feel" that looks like every other app.

This happens because intent lives in prose, but code generation pulls from patterns. The gap between them is where defaults win.

The process below helps. But process alone doesn't guarantee craft. You have to catch yourself.

---

Default Operating Rules

1) Research over vibes

When recommending layout, hierarchy, navigation placement, scanning patterns, or motion — tie it to research and user behavior. Cite sources in the report when relevant.

2) Distinctive over generic

Actively avoid "AI slop" defaults (generic fonts, purple gradients, three-card grids everywhere, Inter/Roboto/Arial, predictable layouts). If the user requests a generic SaaS look, do it intentionally — otherwise propose a more distinctive direction.

3) Accessibility is non-negotiable

Ship WCAG AA as a baseline (keyboard, focus, labels, contrast, reduced motion). Use references/accessibility.md.

4) Implementation-first deliverables

Every critique must translate into:

• a prioritized plan
• specific code edits (diffs or file replacements)
• validation steps (a11y + responsive + performance)

---

Where Defaults Hide

Defaults don't announce themselves. They disguise themselves as infrastructure.

Typography feels like a container. But typography isn't holding your design — it IS your design. A bakery management tool and a trading terminal might both need "clean, readable type" — but the type that's warm and handmade is not the type that's cold and precise.

Navigation feels like scaffolding. But navigation isn't around your product — it IS your product. Where you are, where you can go, what matters most.

Data feels like presentation. A progress ring and a stacked label both show "3 of 10" — one tells a story, one fills space.

Token names feel like implementation detail. But --ink and --parchment evoke a world. --gray-700 and --surface-2 evoke a template.

The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design.

---

Intent First

Before touching code, answer these. Not in your head — out loud.

Who is this human? Not "users." The actual person. Where are they when they open this? What's on their mind? A teacher at 7am with coffee is not a developer debugging at midnight is not a founder between investor meetings.

What must they accomplish? Not "use the dashboard." The verb. Grade these submissions. Find the broken deployment. Approve the payment.

What should this feel like? Say it in words that mean something. "Clean and modern" means nothing. Warm like a notebook? Cold like a terminal? Dense like a trading floor? Calm like a reading app?

If you cannot answer these with specifics, stop. Ask the user. Do not guess. Do not default.

Every Choice Must Be A Choice

For every decision, explain WHY:

• Why this layout and not another?
• Why this color temperature?
• Why this typeface?
• Why this spacing scale?
• Why this information hierarchy?

If your answer is "it's common" or "it's clean" — you've defaulted. The test: If you swapped your choices for the most common alternatives and the design didn't feel meaningfully different, you never made real choices.

Intent Must Be Systemic

If the intent is warm: surfaces, text, borders, accents, semantic colors, typography — all warm. Saying "warm" and using cold colors is not following through. Intent is not a label — it's a constraint.

---

Design System Generation (Optional but Powerful)

When you want a research-backed recommendation from the database, use:

python3 skills/ui-ux-myth/scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]

This searches 5 domains in parallel and returns: pattern, style, colors, typography, effects, and anti-patterns.

Persist the design system for future sessions:

python3 skills/ui-ux-myth/scripts/search.py "<query>" --design-system --persist -p "Project Name"

Creates design-system/MASTER.md + per-page overrides in design-system/pages/.

Domain searches for supplemental detail:

python3 skills/ui-ux-myth/scripts/search.py "<keyword>" --domain <domain> [-n <max_results>]

Need	Domain	Example
More style options	style	--domain style "glassmorphism dark"
Chart recommendations	chart	--domain chart "real-time dashboard"
UX best practices	ux	--domain ux "animation accessibility"
Alternative fonts	typography	--domain typography "elegant luxury"
Landing structure	landing	--domain landing "hero social-proof"

Stack guidelines:

python3 skills/ui-ux-myth/scripts/search.py "<keyword>" --stack html-tailwind

Available: html-tailwind (default), react, nextjs, vue, svelte, swiftui, react-native, flutter, shadcn, jetpack-compose

Utility scripts:

• scripts/ui_slop_scan.py — flags common template signals in a repo
• scripts/component_inventory.py — quick component inventory

---

Product Domain Exploration

Generic output: Task type → Visual template → Theme Crafted output: Task type → Product domain → Signature → Structure + Expression

Do not propose any direction until you produce all four:

Domain: Concepts, metaphors, vocabulary from this product's world. Minimum 5.

Color world: What colors exist naturally in this product's domain? Not "warm" or "cool" — go to the actual world. If this product were a physical space, what would you see? List 5+.

Signature: One element — visual, structural, or interaction — that could only exist for THIS product. If you can't name one, keep exploring.

Defaults: 3 obvious choices for this interface type — visual AND structural. You can't avoid patterns you haven't named.

Proposal Requirements

Your direction must explicitly reference:

• Domain concepts you explored
• Colors from your color world exploration
• Your signature element
• What replaces each default

The test: Read your proposal. Remove the product name. Could someone identify what this is for? If not, it's generic.

---

Craft Foundations

Subtle Layering

Regardless of direction, product type, or visual style — this principle applies to everything. You should barely notice the system working. When you look at Vercel's dashboard, you don't think "nice bor

---

Content truncated.