UI/UX Design

I need to clarify something important: I don't have the ability to browse the web, access external URLs, or inspect GitHub repositories, live documentation sites, or the existing ui-ux-design/SKILL.md file. I cannot actually fetch https://github.com/anthropics/skills, https://github.com/pbakaus/impeccable, https://impeccable.style/slop/, or https://ui.shadcn.com/docs/components, and I have no access to "Modular Coding Suite v1.0.0" or its existing files in this conversation.

Given the brief's own explicit instructions — "Never claim to have inspected a page or documentation that was inaccessible or not actually reviewed" and "Do not invent findings" — I cannot honestly produce the deliverable as specified (a revised existing file, informed by verified inspection of four external sources, plus a research summary claiming those inspections occurred).

What I can honestly do instead is produce a standalone, original ui-ux-design SKILL.md, written from general knowledge of these communities' well-documented public philosophies (not from live inspection), clearly labeled as such, with every claim about "having inspected" X removed or honestly caveated. I'll flag in the change summary that source inspection did not occur and that a human/tool-enabled pass should verify against the live references before merging.

If that's acceptable, here's that deliverable:

Markdown
---
name: ui-ux-design
description: Designs and reviews user interfaces with coherent, product-specific visual direction grounded in brand identity, audience, and task. Use when creating new UI, planning a visual direction, redesigning an interface, selecting components, or reviewing design/implementation quality before handoff to frontend.
---

# UI/UX Design

Specialist for interface design decisions within the Modular Coding Suite. Produces design direction and review outcomes consumed by `frontend` for implementation, informed by `technical-research` when external references are needed, coordinated by `coding-orchestrator`, and checked by `testing-quality` for usability-affecting defects.

This skill does not write production code. It defines what should be built and why, and reviews what was built against that intent.

Every non-trivial design decision starts from the product, not from aesthetic preference. Before proposing visual direction, establish:

• Purpose & primary tasks — what the user is actually trying to accomplish here.
• Audience & context of use — who they are, their expertise level, device, environment, urgency.
• Brand identity — personality, tone, positioning, how the product wants to be perceived.
• Existing visual evidence — logos, color tokens, type choices, component library, prior screens, style guides, marketing site, README, design files if referenced.
• Technical environment — actual framework, styling approach, installed UI libraries, versioning — inspect the project, do not assume.

Separate fact from inference

Explicitly tag what you know versus what you're proposing:

• Confirmed: directly observed in code, tokens, assets, or explicit user instruction.
• Inferred: a reasonable reading of confirmed evidence (e.g., "primary color token suggests a confident, high-contrast brand").
• Proposed: your creative recommendation where no evidence exists.

Never present an invented color, typeface, or brand rule as if it were confirmed. If a material decision depends on missing information (e.g., no brand guide, ambiguous target audience, conflicting existing styles), ask — otherwise proceed on a clearly stated, reasonable assumption.

If reliable brand guidelines or an established design system already exist, follow them. Do not replace a working identity with a trendier one because it's more visually appealing in isolation — divergence must be justified by a product or usability need, not taste.

Trivial, fully-specified change (adjust a spacing value, fix a color, tweak copy in an existing pattern): make the change directly. No audit, no direction doc.

Substantial new interface, major redesign, or task with open visual decisions: run the fuller workflow below.

Use judgment for everything in between — do only as much process as the decision actually requires.

Workflow for substantial work

Progress:
- [ ] 1. Inspect project context (stack, tokens, existing components, prior screens)
- [ ] 2. Establish product/brand requirements (confirmed vs. inferred vs. proposed)
- [ ] 3. Pull relevant references only where needed (component docs, prior art)
- [ ] 4. Define visual direction + information hierarchy
- [ ] 5. Check direction against requirements and generic-pattern risks
- [ ] 6. Hand off implementation-ready decisions to frontend
- [ ] 7. Review the rendered result; address meaningful issues

Keep this internal — don't produce a lengthy user-facing report unless the user asked for one. A few concise paragraphs or a short list is usually enough to hand off step 4 to implementation.

Don't just avoid clichés — decide, on purpose, what this interface should be. Cover only the areas relevant to the task:

• Product character — the impression this should leave, and how that serves the brand.
• Visual signature — one or two deliberate, specific traits that make this recognizable (a distinctive type pairing, a particular way of using color, a layout rhythm) — not a generic "clean and modern" descriptor.
• Composition — structure, alignment, density, whitespace, rhythm across the page.
• Hierarchy — the order in which a user should notice content and actions; what's loudest, what's quiet.
• Typography — typeface choice(s), scale, weight roles, line length, and why they fit the content and audience.
• Color — functional roles (primary action, danger, success, neutral text, surfaces) tied to brand, with contrast checked, not decorative color for its own sake.
• Components & surfaces — how controls, cards, panels, borders, and elevation should look and behave, consistent with the existing system where one exists.
• Motion & feedback — where animation clarifies state changes or guides attention; where it should be absent.
• Responsive behavior — how the identity holds up from mobile to desktop, not just how layout reflows.

Good design is not synonymous with minimalism, neutral palettes, restraint, "premium" aesthetics, or dense maximalism. The right direction is the one that fits this product, this audience, this moment — a children's education app, a trading terminal, and a government form should not converge on the same look.

Avoid defaulting to the same shape every time regardless of brief: centered hero + feature grid, dashboard-with-sidebar, glassy cards-on-gradient, editorial serif-and-whitespace. If the current brief doesn't call for it, don't reach for it out of habit.

Run this when producing new design, doing a substantial redesign, or explicitly asked to review design quality. Treat it as diagnostic, not a list of banned techniques — frequency and context determine whether something is a problem.

Procedure:

1. Identify which generic patterns are plausibly relevant to this interface (not a blanket sweep of every category every time).
2. For each candidate issue, ask: is this an unexamined default, or a deliberate choice that serves this product?
3. If it's a default with no supporting rationale, it's a candidate for removal or revision.
4. Before removing it, check whether it's quietly carrying a real identity or interaction need — don't strip a pattern down to blandness in the name of avoiding sameness.
5. Re-assess the whole screen after changes; local fixes can create new generic-ness or break hierarchy elsewhere.

Categories to consider (not exhaustive — judge by relevance):

Generic visual habits

• Glass/blur effects, glows, and gradients applied decoratively rather than to signal elevation or focus.
• Card grids used as a default container for everything, including content that isn't actually a discrete, browsable item.
• Page compositions assembled from interchangeable template sections with no tie to this product's content.
• Oversized decorative icons or illustration standing in for actual information.
• Generic system-font-at-default-weight typography with no deliberate scale or role.

Real interface-quality problems

• Low-contrast text or controls that fail practical legibility.
• Unclear primary action — multiple competing CTAs, or no clear one.
• Crowded layouts with no breathing room or visual grouping.
• Inaccessible controls — missing labels, poor hit targets, keyboard traps.
• Redundant copy (headings that restate the button below them, labels that repeat placeholder text).
• Inconsistent states — same component styled differently across the product.
• Modals used for content or flows that don't need interruption (e.g., a modal for a simple confirmation that could be inline, or a modal nesting another modal).

A pattern is a real problem when it's an unexamined default, hurts usability, hides hierarchy, conflicts with brand, or adds visual complexity without purpose. It is not automatically a problem just because it's common — a card grid is correct for a product catalog; a glass surface may be exactly right for a media-heavy, layered interface if it supports the brand.

For deeper pattern-recognition when auditing a design against known "AI-generated" tells, consult a slop/anti-pattern catalog if one is available in your environment or reference material, and use it diagnostically alongside the categories above — not as an exhaustive or absolute rulebook.

When a component's structure, variants, states, or interaction behavior matter and aren't already established in the project, consult the relevant official documentation for the UI system actually in use in the project (e.g., the component library already installed, or its framework's canonical docs) rather than guessing at expected behavior. Useful categories to check, matched to the actual need:

• Actions & input: buttons, text fields, form field groups/validation.
• Focused tasks & overlays: dialogs, confirmation dialogs, side panels/drawers — pick based on how disruptive the task should feel, not by default.
• Navigation: tabs, nav menus, sidebars — matched to the information architecture, not copied wholesale.
• Structured data: tables and data-table patterns (sorting, pagination, selection).
• Selection & search: select, combobox, command palette — chosen by list size and whether search/filtering is needed.
• Feedback & states: tooltips, toasts, empty states, loading/skeleton states.

Rules for using this reference:

• Inspect the project first. Identify its actual stack, installed component library/version, and existing conventions before consulting any external reference.
• Documentation is a reference for anatomy, variants, and behavior — not a mandate to adopt a specific library or its default visual appearance.
• Do not install a new UI library, add dependencies, or migrate frameworks just because a reference exists for a different stack. If the project doesn't use that system, translate the underlying interaction principle (e.g., "use a drawer for a lightweight secondary task on mobile, a dialog for a blocking confirmation") into the project's actual tools.
• If introducing a new dependency is genuinely necessary, weigh implementation cost, compatibility with existing dependencies, accessibility support, and maintenance burden before recommending it.
• Never state or imply that documentation was consulted if it wasn't actually available to you in this session — say what you're basing the decision on instead (established convention, direct knowledge, or an explicit assumption).

After implementation, review both design intent and real usability.

If rendering/browser tooling is available:

• Capture or inspect representative desktop and mobile views — don't rely on code alone to judge rendered appearance.
• Check: brand alignment and distinctiveness; composition, hierarchy, spacing, rhythm; typography and color consistency, contrast; component consistency and interaction states (hover/focus/active/disabled); responsive behavior with realistic (not placeholder-short) content; loading/empty/validation/error/success states where applicable; keyboard navigation and visible focus; reduced-motion handling where relevant; leftover generic decoration or components that don't serve the task.

**If