UI/UX Design

I don't have the ability to access external URLs or inspect the existing ui-ux-design/SKILL.md file from the Modular Coding Suite in this context — I have no browsing tool invoked and no file was provided in this conversation. I must be honest about that rather than fabricate research findings or pretend to have read files I never saw.

Given the brief's explicit acceptance criteria require actually inspecting four external sources and the existing skill file, and fabricating that inspection would violate the task's own stated principles (honest reporting, no invented findings, no claiming verification that didn't occur), I cannot produce a legitimate "revised SKILL.md" that claims to be grounded in research I did not perform.

What I can do responsibly: produce a best-effort skill upgrade based on well-established, generally known public knowledge of these sources (Anthropic's frontend-design skill philosophy, shadcn/ui's component catalog, and common "AI slop" critiques), while being transparent that I did not browse the live pages in this session. Below is that deliverable, with honest caveats in the reporting sections.

Markdown
---
name: ui-ux-design
description: Designs coherent, brand-aligned, and usable interfaces by grounding visual decisions in product purpose, audience, and existing identity rather than generic templates. Use when creating new interfaces, planning substantial redesigns, selecting visual direction, reviewing design quality, or deciding how UI components should look and behave before frontend implementation.
---

# UI/UX Design

Specialist for **design decisions**: what an interface should look like, how it should be organized, and why — grounded in the specific product, brand, and users. This skill does not write implementation code; it hands off clear, implementation-ready direction to `frontend`, and coordinates with `coding-orchestrator`, `technical-research`, and `testing-quality` as needed.

The central goal is **fit**, not decoration: every design decision should be traceable to the product's purpose, audience, brand, or constraints — not to "what looks good" or "what avoids looking AI-generated" in the abstract.

Before any significant visual decision, establish what is actually known about the product. Classify everything you learn into three buckets, and keep them visibly separate in your reasoning and handoff notes:

• Confirmed — facts found in the codebase, design tokens, style guides, existing screens, brand assets, copy, or explicit user statements.
• Inferred — reasonable interpretations drawn from confirmed facts (e.g., "uses a playful illustration style across marketing pages → likely wants a friendly, approachable tone in-app").
• Proposed — new creative direction you are recommending, clearly labeled as a suggestion, not a fact.

Never present a proposed or inferred detail (a color, a typeface, a tone, a layout convention) as an established brand fact. If a decision would materially change the outcome and the needed information is missing, ask the user. Otherwise, make an explicit, stated assumption and proceed.

Inspect, when available:

• Product purpose and the primary tasks users come to perform.
• Target audience: expertise level, context of use, device, accessibility needs.
• Brand identity: name, tone of voice, existing marketing material, logos, imagery.
• Existing design tokens, component libraries, CSS variables, theme files.
• Existing screens and interaction patterns already shipped in the product.
• Technical stack and constraints (framework, CSS approach, installed UI libraries, versions).

If a real design system or brand guideline already exists, follow it. Do not replace an established identity with a more fashionable aesthetic. Internal taste is not a valid reason to override confirmed brand decisions.

If brand information is incomplete, preserve every confirmed element you find, and propose the rest explicitly as proposals — never as discovered facts.

Match the depth of process to the actual size of the decision. Do not run a full design process for a one-line style fix.

Trivial, fully-specified change (e.g., "increase padding on this card," "this icon overlaps the input text," "change this button to the secondary variant"): make the fix directly. No brand review, no direction document, no catalog pass. If investigation reveals it's actually an implementation bug (CSS specificity, incorrect markup) rather than a design decision, hand it to frontend/debugging instead of treating it as a design task.

Substantial new interface, major redesign, or a task with real open visual questions:

Progress:
- [ ] 1. Inspect project context (stack, tokens, existing screens, brand assets)
- [ ] 2. Establish product + brand requirements (confirmed / inferred / proposed)
- [ ] 3. Pull relevant references only where genuinely useful (see below)
- [ ] 4. Define a concise visual direction and information hierarchy
- [ ] 5. Check the direction against requirements and generic-pattern risks
- [ ] 6. Hand off implementation-ready decisions to `frontend`
- [ ] 7. Review the rendered result; report what was and wasn't verified

Keep this proportional: a direction document for a single new settings page should be a few bullet points, not a lengthy report. Don't produce multiple competing proposals or user-facing design essays unless asked.

This is the core creative output. For each area, make a deliberate choice and state why it fits this product — don't just avoid known clichés.

• Product character — What impression should this convey, and how does that relate to the brand (e.g., a clinical lab tool should read as precise and calm, not playful)?
• Visual signature — One or two purposeful, distinctive traits that make this interface recognizable as this product, not interchangeable with any other SaaS app.
• Composition — Page structure, alignment, density, rhythm, whitespace — driven by what the content and tasks actually need.
• Hierarchy — What should the user notice first, second, third? Tie this to the primary task, not to visual novelty.
• Typography — Typeface choice, scale, weight roles, and readability, justified by audience and context (dense data tool vs. marketing page vs. consumer app).
• Color — Roles (primary action, danger, success, neutral surfaces), contrast, and alignment with brand palette — not just an aesthetically pleasing combination.
• Components & surfaces — How controls, groups, borders, elevation, and backgrounds should read, consistent with existing patterns unless there's a reason to evolve them.
• Motion & feedback — Where animation clarifies state changes or guides attention; avoid decorating every element with transitions.
• Responsive behavior — How identity and usability survive across breakpoints, not just "it doesn't break."

Different products should land in genuinely different places here. A children's education app, a trading terminal, and an internal admin panel should not converge on the same layout, palette, and card treatment just because all three were "well designed."

Do not treat minimalism, neutral palettes, restraint, or "premium" styling as the default correct answer. The right answer depends on the product in front of you.

When doing a design review — for a new design, a substantial redesign, or a dedicated quality pass — check for two distinct categories of issue:

1. Generic design habits that make unrelated products look interchangeable: unmotivated glass/blur effects, gratuitous gradients and glow, cards used as a default wrapper for everything, copy-pasted page templates, oversized decorative icons, generic sans-serif stacks with no hierarchy, weak contrast, boilerplate microcopy, overused modals for things that don't need interruption.
2. Concrete usability problems: insufficient contrast ratios, unclear primary actions, crowded layouts, inaccessible or unlabeled controls, inconsistent component states, redundant or unclear copy, missing loading/empty/error states.

For each flagged pattern, reason explicitly:

• Is this an unexamined default, or a deliberate choice that serves this product's brand or task?
• Does it actually harm clarity, usability, or performance here?
• Would removing it also remove something that gives this interface identity?

A pattern is only a problem when it's an unmotivated default, degrades usability, obscures hierarchy, conflicts with the established brand, or adds complexity without payoff. Glass effects, card grids, bold typography, and animation are not inherently wrong — they're wrong when applied without reason. Keep this check proportional: review the patterns relevant to the actual project and task, not every possible category every time.

(When a curated catalog of generic AI-design patterns is available in your environment, consult it as a diagnostic checklist for this step — a source of examples and reasoning to sharpen judgment, not a list of forbidden techniques to enforce mechanically.)

When a task involves a recognizable UI pattern (data entry, navigation, overlays, structured data, selection/search, feedback states), consult the relevant official documentation for component anatomy, variants, interaction states, and accessibility behavior — whether that's shadcn/ui, Radix, Material, or whatever the project's actual stack provides.

Before doing this:

1. Inspect the project's real stack first — framework, installed component libraries, existing patterns, dependency manifest, versions. Do not assume React, Tailwind, or shadcn/ui are present.
2. Pick the documentation source matching what's actually installed, or the closest applicable reference for translating general interaction patterns (e.g., shadcn/ui's Dialog/Drawer/Command docs as a reference for focused-task and search-overlay behavior even in a Vue or vanilla-JS project).
3. Extract structural and behavioral guidance (states, keyboard interaction, when to use a drawer vs. a dialog vs. inline expansion) rather than visual appearance.
4. Re-skin and restructure to match the project's established visual system — never ship the reference library's default look as the final design.

Never add a new UI library, framework, or dependency solely because a reference documents it. Only recommend a new dependency when the existing stack genuinely cannot meet a real requirement, and weigh implementation cost, compatibility, accessibility, and maintenance before suggesting it.

After implementation, when rendering or browser tooling is actually available, review representative desktop and mobile views for:

• Brand alignment and distinctiveness against the established direction.
• Composition, hierarchy, spacing, and rhythm.
• Typography and color consistency, with genuinely readable contrast.
• Component consistency and correct interaction states (hover, focus, disabled, loading, error).
• Responsive behavior under realistic content lengths (long names, empty lists, overflow).
• Loading, empty, validation, error, and success states where applicable.
• Keyboard navigation, visible focus rings, and reduced-motion behavior where relevant.
• Leftover unnecessary decoration or components that don't serve the task.

Use actual screenshots or rendered previews when the tooling allows it — code inspection alone cannot confirm the real rendered appearance. If visual tooling is unavailable, perform the best feasible code-level review and say so explicitly. Never state that rendering, accessibility testing, or visual verification happened if it did not.