frontend-ui-system

TotalClaw 作者 minthymed-sh v1.0.0

使用 v0.dev 类型的方法设计和实现应用程序、网站和仪表板的高质量界面:清晰的视觉方向、设计系统、强大的视觉层次结构、可重用的组件、移动优先、UI 一致性和迭代审查。

源码 ↗

安装 / 下载方式

TotalClaw CLI推荐
totalclaw install totalclaw:minthymed-sh~frontend-ui-system
cURL直接下载,无需登录
curl -fsSL https://skills.taituai.com/api/skills/totalclaw%3Aminthymed-sh~frontend-ui-system/file -o frontend-ui-system.md
Git 仓库获取源码
git clone https://github.com/openclaw/skills/commit/89ab0da37a2b78ff89cf57050943bf657cad34f4
## 概述(中文)

使用 v0.dev 类型的方法设计和实现应用程序、网站和仪表板的高质量界面:清晰的视觉方向、设计系统、强大的视觉层次结构、可重用的组件、移动优先、UI 一致性和迭代审查。

## 原文

# Frontend UI System

## Propósito

Esta skill existe para que el agente diseñe e implemente interfaces de usuario con un nivel visual y estructural mucho más alto que una UI genérica.

El objetivo no es solo producir código funcional. El objetivo es producir una interfaz:

- limpia
- moderna
- coherente
- comercial
- usable
- visualmente jerárquica
- reusable a nivel de componentes
- lista para crecer como producto real

La referencia mental es trabajar más cerca del nivel de criterio de un product designer + frontend engineer, y no como un simple generador de JSX o HTML.

---

# Principio fundamental

**No escribir código hasta tener claridad visual suficiente.**

El diseño no es decoración.  
El diseño es estructura, jerarquía, intención, claridad y sistema.

Cada decisión visual debe tener una razón funcional.

---

# Meta principal

Cuando el usuario pida una app, una web, una landing, un dashboard, una pantalla o una mejora visual, esta skill debe ayudar a producir un resultado que:

- se vea mejor desde la primera iteración
- tenga mejor taste visual por defecto
- evite layouts genéricos o desordenados
- mantenga consistencia entre pantallas
- use un sistema visual claro
- implemente bien el frontend, no solo lo maquille

---

# Cuándo usar esta skill

Usa esta skill cuando el usuario pida cosas como:

- diseñar una app
- rediseñar una pantalla
- mejorar una UI
- hacer una landing page
- construir un dashboard
- crear una web moderna
- hacer una interfaz más premium
- refinar frontend
- hacer una app mobile-first
- mejorar UX/UI
- crear componentes visualmente consistentes
- transformar una interfaz básica en algo más moderno y comercial

También úsala cuando el usuario diga frases vagas como:

- “hazlo más moderno”
- “hazlo más premium”
- “hazlo más limpio”
- “se ve muy básico”
- “quiero que se vea profesional”
- “quiero que parezca producto real”
- “hazlo como una app seria”
- “quiero una UI bonita”

---

# Resultado esperado

Esta skill debe hacer que el agente:

1. piense antes de codificar  
2. proponga dirección visual  
3. documente un mini design system  
4. defina arquitectura de pantallas  
5. implemente con componentes reutilizables  
6. revise jerarquía visual, spacing y consistencia  
7. itere si el resultado sigue viéndose genérico o flojo

---

# FASE 0: diagnóstico inicial

Antes de diseñar o implementar, responder internamente estas preguntas:

## Preguntas base

1. ¿Qué tipo de producto es?
- App móvil
- Web app
- Landing page
- Dashboard
- E-commerce
- SaaS
- Plataforma interna
- Portal
- Sistema administrativo
- Sitio institucional

2. ¿Quién es el usuario objetivo?
- consumidores
- empresas
- profesionales
- jóvenes
- técnicos
- administradores
- clientes finales
- personal operativo

3. ¿Cuál es la acción principal del usuario?
- comprar
- reservar
- registrarse
- explorar
- consultar
- crear contenido
- subir información
- revisar métricas
- gestionar datos
- agendar
- confirmar una acción

4. ¿Qué personalidad debe transmitir el producto?
- premium
- confiable
- moderno
- amigable
- técnico
- corporativo
- juvenil
- sobrio
- innovador
- deportivo
- elegante

5. ¿Cuál es la prioridad del contexto?
- conversión
- claridad
- velocidad
- confianza
- facilidad de uso
- densidad de información
- exploración
- mobile-first
- desktop-first

## Regla
No pasar a implementación sin haber aclarado mentalmente estas cinco cosas.

---

# FASE 1: dirección visual

## Regla obligatoria
Siempre que no exista una dirección visual completamente definida, proponer **2 o 3 estilos visuales distintos** antes de implementar.

## Formato de propuesta visual

Para cada estilo, documentar:

**Estilo [Letra]: "[Nombre conceptual]"**

- Concepto: descripción de 1 línea
- Paleta: color primario + neutrales + acento
- Tipografía: familia y personalidad
- Personalidad: 3 adjetivos
- Fortaleza: por qué funcionaría bien
- Riesgo: qué podría salir mal si se exagera

## Ejemplo de estructura

**Estilo A: "Corporate Trust"**
- Concepto: profesional, serio y confiable
- Paleta: azul marino + grises + blanco + acento sobrio
- Tipografía: Inter
- Personalidad: confiable, corporativo, claro
- Fortaleza: transmite seguridad
- Riesgo: puede sentirse algo genérico

**Estilo B: "Modern Minimal"** ⭐ RECOMENDADO
- Concepto: limpio, contemporáneo y premium
- Paleta: negro suave + blanco + gris neutro + verde lima o azul sobrio
- Tipografía: Geist / Inter / Plus Jakarta Sans
- Personalidad: moderno, premium, tecnológico
- Fortaleza: elegante y muy adaptable
- Riesgo: si se exagera, puede verse vacío

**Estilo C: "Friendly Product"**
- Concepto: accesible y moderno
- Paleta: tonos amigables con neutrales limpios
- Tipografía: Plus Jakarta Sans / Manrope
- Personalidad: accesible, cálido, moderno
- Fortaleza: gran cercanía con el usuario
- Riesgo: puede perder seriedad en ciertos contextos

## Recomendación obligatoria
Marcar uno como **RECOMENDADO** y justificar por qué encaja mejor con el producto, el usuario y la acción principal.

---

# FASE 2: mini design system

Una vez elegida la dirección visual, documentar un mini sistema antes de codificar.

## 2.1 Tokens de color

Definir mínimo estos tokens:

| Token | Uso |
|---|---|
| `primary` | marca, CTA principal, foco |
| `primary-foreground` | texto sobre primary |
| `background` | fondo principal |
| `foreground` | texto principal |
| `card` | fondo de superficies |
| `card-foreground` | texto en cards |
| `muted` | fondos secundarios |
| `muted-foreground` | texto secundario |
| `accent` | badges, highlights, estados activos |
| `accent-foreground` | texto sobre accent |
| `border` | separadores y bordes |
| `destructive` | errores y acciones destructivas |
| `success` | confirmaciones si aplica |
| `warning` | alertas si aplica |

## Reglas de color

- Usar preferentemente **máximo 5 colores dominantes** en la experiencia.
- Tener 1 color primario claro.
- Usar 2 o 3 neutrales máximos.
- Mantener 1 o 2 acentos funcionales.
- Preferir colores sólidos frente a gradientes innecesarios.
- Usar nombres semánticos, no colores directos, cuando se implementen tokens.
- Verificar contraste suficiente.
- El acento debe ayudar a la jerarquía, no competir con todo.

## Evitar
- demasiados colores compitiendo
- acentos por todas partes
- gradientes sin propósito
- colores chillones en exceso
- usar muchos tonos sin sistema

---

## 2.2 Tipografía

Definir:

- familia principal
- pesos usados
- escala base
- line height
- rol de headings, body, caption, labels

## Reglas tipográficas

- Máximo 2 familias tipográficas.
- Tamaño mínimo recomendado para body: 14px.
- Headings con peso 600-700.
- Body con 400-500.
- Mantener line-height cómodo: 1.4 a 1.6.
- Limitar variedad de tamaños.
- La tipografía debe reforzar personalidad y legibilidad.

## Escala sugerida

- 14
- 16
- 18
- 20
- 24
- 30
- 36
- 48

No hace falta usar todos. Solo los necesarios.

---

## 2.3 Espaciado

Definir una unidad base y una escala consistente.

### Recomendación
Unidad base: 4px

Escala común:
- 4
- 8
- 12
- 16
- 20
- 24
- 32
- 40
- 48
- 64
- 80

## Reglas de spacing

- El whitespace es una de las herramientas más importantes.
- Mejor pecar por más aire que por saturación.
- El spacing debe marcar agrupación lógica.
- Elementos relacionados: gaps más cortos.
- Secciones distintas: gaps más amplios.
- Repetir la misma lógica de espaciado entre pantallas.

## Señal de mala UI
Si todo está muy junto, la UI se percibe barata o improvisada.

---

## 2.4 Border radius

Definir radios por nivel.

Sugerencia:
- XS: 6px
- SM: 8px
- MD: 12px
- LG: 16px
- XL: 20px o 24px
- Full: 9999px

## Regla
Usar radios consistentes según tipo de componente.  
No mezclar demasiados radios diferentes sin motivo.

---

## 2.5 Sombras y profundidad

Las sombras deben ser suaves y escasas.

### Niveles sugeridos
- ninguna
- suave
- media
- fuerte solo en casos muy puntuales