victor-lis-bronzo/rws-skill

/grill-design

Objetivo: definir cómo la aplicación debe verse y comportarse para el usuario final, apoyado en patrones consolidados y en productos reales, y registrar esto de forma persistente.

Preparación (silenciosa)

1. Leer wiki/index.md, wiki/overview.md, especificaciones relacionadas en wiki/ui-specs/ y schema/design-system.md (si existe).
2. Inspeccionar la UI existente en el código (biblioteca de componentes, tokens, configuración de Tailwind, pantallas similares).
3. Leer el catálogo de patrones.
4. Si la funcionalidad no tiene /grill previo y las reglas de negocio son inciertas, sugerir ejecutar /grill primero.

Reglas de conducción

1. Una pregunta por vez, con recomendación justificada.

2. Toda pregunta de diseño viene con sugerencias concretas, en el formato:

   **Pregunta:** ¿Cómo debe navegar el usuario por los 2.000 pedidos?
   
   | Opción | Patrón | Referencias (qué copiar) | Pros | Contras |
   |---|---|---|---|---|
   | A ⭐ | Tabla de datos + filtros facetados + vistas guardadas | **Stripe Dashboard** (chips de filtro sobre la tabla), **Linear** (vistas guardadas en la barra lateral) | Escala, usuarios avanzados | Peor en móvil |
   | B | Maestro-Detalle | **Gmail** (lista + lectura lado a lado) | Contexto preservado | Requiere pantalla ancha |
   | C | Cuadrícula de tarjetas | **Airbnb** (tarjetas con foto) | Visual | Difícil comparar |
   
   **Recomiendo A** porque el público es operativo, de escritorio, y compara estados/valores.
   

3. Las referencias deben ser apps reales y afines al dominio del proyecto (fintech → Nubank, Stripe, Mercury; productividad → Linear, Notion; marketplace → Airbnb, Mercado Libre; etc.). Diga qué exactamente copiar (un detalle específico), no solo el nombre.

4. Si el agente tiene búsqueda web, puede investigar ejemplos (Mobbin, Page Flows, Dribbble) para enriquecer.

5. Siempre que sea posible, muestre un wireframe ASCII de la opción recomendada.

6. Respete el design system existente; solo proponga cambios en él explícitamente.

Dimensiones (recorrer lo que sea relevante, en este orden)

#	Dimensión	Preguntas típicas	Patrones comunes a sugerir
1	Público y contexto	¿Quién es? Frecuencia de uso? ¿Escritorio/móvil? Nivel técnico?	— (define el resto)
2	Recorrido / flujo de usuario	¿De dónde viene, qué objetivo, hacia dónde va? ¿Pasos?	Wizard, hub-and-spoke, flujo lineal
3	Arquitectura de información	¿Qué pantallas? ¿Jerarquía? ¿Navegación?	Barra lateral, pestañas, barra inferior, ⌘K, migas de pan
4	Layout y jerarquía visual	¿Punto focal? ¿Densidad? ¿Cuadrícula? ¿Responsividad?	Maestro-detalle, dashboard de KPI, vista dividida
5	Visualización de datos	¿Lista, tabla, tarjetas, gráfico? ¿Búsqueda/filtro/ordenación?	Tabla de datos, kanban, facetas, vistas guardadas
6	Creación y edición	¿Cómo crea/edita? ¿Validación? ¿Guardado?	Modal, drawer, edición inline, autoguardado, stepper
7	Estados	Carga, vacío, error, éxito, parcial, sin permiso, sin conexión	Skeleton, estado vacío educativo, deshacer toast, UI optimista
8	Feedback y micro-interacciones	Confirmaciones, transiciones, hover, atajos	Toast, validación inline, atajos de teclado
9	Design system y tokens	¿Biblioteca (shadcn, Radix, MUI…)? Colores semánticos, tipografía, espaciado, modo oscuro	Tokens semánticos, escala 4/8px
10	Accesibilidad	Teclado, foco, contraste AA, lector de pantalla, prefers-reduced-motion	Skip links, focus ring, patrones ARIA
11	Contenido y tono	Microcopy, idioma, tono de voz, mensajes de error	—
12	Onboarding y activación	¿Primer uso? ¿Datos de ejemplo?	Lista de verificación, galería de plantillas, datos de muestra

Síntesis

Presente la especificación rellenando la plantilla ui-ux-spec.md, incluyendo:

• tabla Patrones adoptados (patrón → dónde → referencia → motivo);
• tabla Referencias (app → qué copiar → qué evitar);
• wireframes ASCII de las pantallas principales;
• matriz de estados por componente;
• tokens/reglas nuevas propuestas para el design system.

Y la tabla de grabaciones:

Destino	Archivo	Acción
wiki	wiki/ui-specs/<pantalla-o-flujo>.md	/wiki:add
wiki	wiki/concepts/<funcionalidad>.md (enlace a la especificación)	/wiki:increment
schema	schema/design-system.md	/schema:add (1ª vez) o /schema:increment

Plan de Implementación de UI (Tareas / Tickets)

Tarea	Vertical	Depende de	Prioridad	Acción
wiki/tasks/<slug-de-la-pantalla>.md	ui	-	medium	/ticket:new (wiki + issue)

Aprobación explícita (gate)

"¿Aprueba la especificación de UI/UX, las grabaciones en el design system y la creación de las tareas (+ issues en GitHub)? (sí / ajustar)" — sin aprobación inequívoca, no grabe nada.

Formalización (tras aprobación)

1. /wiki:add → wiki/ui-specs/<slug>.md (type: ui-spec).
2. /wiki:increment en las páginas de funcionalidad/entidad relacionadas.
3. /schema:add o /schema:increment → schema/design-system.md (plantilla design-system-rules.md).
4. Ejecute /ticket:new para cada tarea de UI planificada (componentes, pantallas, interacciones), con las etiquetas vertical:ui (o vertical de la funcionalidad) y status:planned.
5. Agregue en wiki/log.md: ## [AAAA-MM-DD] grill-design | <pantalla/flujo> con las páginas y tareas creadas.
6. Sugerir próximos pasos: /implement <tarea-de-ui>, prototipo, pantallas vecinas sin especificación.