---
name: mcp-ui-ux
description: >
  Single entry point and router for all UI/UX and design work. Use for any interface task — user research, product flows, information architecture, visual design and polish, accessibility, responsive behavior, motion, design systems, CSS architecture, forms, data tables, theming, typography, internationalization, metadata, frontend review, web performance, framework-specific work (shadcn, bootstrap, React), legacy UI modernization, or UI testing. This skill routes to internal specialist modules under `references/modules/`, loading only the smallest useful context while keeping one standard discoverable skill. Do not use for cross-domain programs that also require backend, data, infrastructure, or release coordination; use mcp-master-orchestrator for those.
---

# MCP UI/UX

Punto d'ingresso unico per il lavoro di UI/UX e design. Indicizza e instrada verso moduli specialistici interni, senza registrare skill standard aggiuntive, caricare indiscriminatamente l'intera suite o creare ownership concorrente sul codice.

## Modello di dispatch

Le competenze specialistiche UI/UX vivono come **moduli interni** in `references/modules/<nome>/MODULE.md` (es. `references/modules/mcp-accessibility-auditor/MODULE.md`). Solo questo `SKILL.md` partecipa alla discovery standard; Cursor proietta i moduli in regole namespaced separate.

1. Classificare l'intento con `references/routing-matrix.md`.
2. Aprire il `MODULE.md` scelto in `references/modules/<nome>/MODULE.md` e caricare solo le reference pertinenti indicate dal modulo.
3. Per un task ristretto con specialista ovvio, caricare direttamente il modulo corrispondente dopo l'attivazione di questo router.
4. Le skill esterne citate nel routing (`mcp-frontend-performance-debugger`, `mcp-browser-automation`, `mcp-master-orchestrator`) restano skill top-level e si invocano normalmente.

## Protocollo

1. Stabilire se il task e realmente UI/UX.
2. Se l'obiettivo e ambiguo, chiedere una sola domanda mirata.
3. Classificare intento, stack, superficie, output e necessita di runtime.
4. Consultare `references/routing-matrix.md`.
5. Selezionare una skill primaria e al massimo due skill secondarie.
6. Definire ordine, input/output di ogni passaggio e un unico owner delle modifiche.
7. Separare discovery, decisione, implementazione e verifica.
8. Richiedere evidenze e handoff sintetici tra gli specialisti.
9. Chiudere con coverage, modifiche, validazioni e rischi residui.

## Regole permanenti

- Preferire sempre la skill piu specifica.
- Non invocare piu di tre skill per un singolo task, salvo programma esplicitamente multi-fase.
- Non duplicare audit e implementazione tra due skill.
- Non lasciare a piu agenti la scrittura sugli stessi file.
- Trattare le reference `impeccable-*` come playbook portabili: non eseguire hook, agent profile, live server o script vendor non inclusi.
- Risolvere i path `scripts/<modulo>/...` rispetto alla root di questa skill.
- Usare `mcp-browser-automation` per prova runtime e `mcp-frontend-performance-debugger` per profiling sistemico.
- Passare a `mcp-master-orchestrator` quando il task supera il dominio UI/UX.

## Output

1. classificazione del task
2. skill selezionate e motivazione
3. sequenza e ownership
4. evidenze richieste
5. gate di validazione
6. handoff e rischi residui

## References

- [Routing matrix](references/routing-matrix.md)
- [Runtime compatibility](references/runtime-compatibility.md)
- [UI skill selection protocol](references/ui-skill-selection-protocol.md)

I playbook portabili sono in `references/playbooks/impeccable/`: caricare solo quello richiesto dal task, non l'intera libreria.