mobile

ultrahand: mobile

Diseña pantallas de teléfono como un artifact interactivo de Claude que cambia entre tres tamaños de teléfono en orientación vertical y horizontal. Cada regla que aplicas está en references/principles.md, y cada regla cita references/sources.md. Los tamaños y áreas seguras están en references/presets.md.

1. Recopilar requisitos

Pregunta solo lo que no puedas inferir. Resuelve esto antes de dibujar:

• Plataforma: iOS, Android o ambos. Si ambos, usa objetivos de 48 unidades y patrones neutros respecto a la plataforma.
• Alcance: una pantalla o un flujo. Para un flujo, enumera las pantallas y cómo se mueven entre ellas: pestaña, push, hoja o modal de pantalla completa.
• Tarea principal: la única función de cada pantalla. Esa acción debe estar al alcance del pulgar.
• Contenido real: nombres, longitudes, recuentos y las cadenas más largas posibles. No diseñes con lorem ipsum.
• Estados de datos: qué se carga, qué puede estar vacío y qué puede fallar o estar sin conexión.
• Restricciones: colores de marca, fuentes, un sistema de diseño existente y si es una app nativa o web.
• Tema: busca el tema del proyecto (design/THEME.md, *.tokens.json; consulta shared/theme/README.md) antes de elegir cualquier color, tamaño o espaciado. Si hay uno, diseña con él: ejecuta node "${CLAUDE_PLUGIN_ROOT}/shared/theme/css.mjs" <tokens.json> --style --out theme.html, pasa --head theme.html a la compilación, usa solo sus propiedades personalizadas (var(--color-surface), var(--space-gap-group)), y reutiliza los componentes de su inventario. Cuando el diseño necesite algo que el tema no tenga, usa el token más cercano y enumera la adición en preguntas abiertas; no inventes un valor. Sin tema, sigue los no negociables en shared/theme/rules.md y ofrece el skill theme.

2. Leer las referencias

Lee references/principles.md y references/presets.md antes de diseñar. Usa los patrones propios de la plataforma (barra de pestañas, pila de navegación, hojas) en lugar de inventar nuevos.

3. Componer la pantalla

Componentes que pasan sus comprobaciones pueden sumar una pantalla desordenada. Antes de construir, planifica cómo forman secciones y cómo las secciones forman la pantalla, usando las reglas de composición del plugin en shared/composition/principles.md:

• Escribe el mapa de secciones. Para cada pantalla enumera sus secciones (una barra de navegación, el contenido, una acción principal y una barra de pestañas), el trabajo único de cada una, sus miembros ordenados por frecuencia de uso, y su único énfasis. Di qué es contenido principal y qué es cromo: el contenido domina y el cromo se retira.
• Agrupa con espacio. Los espacios dentro de un grupo son claramente menores que los espacios entre grupos; añade un contenedor solo cuando el espacio no pueda mostrar el grupo.
• Un aspecto por rol, un énfasis por sección. Mismo rol, mismo estilo; estado y etiquetas nunca se parecen a botones; el acento fuerte va a un elemento por sección, y los estados seleccionados usan un tratamiento más sutil.
• Mantenlo pequeño. Alrededor de tres tamaños de fuente, un dato en un lugar, miembros frecuentes a la vista y los raros detrás de un menú. Cuando un cambio añada algo, reorganiza primero y añade solo lo que merezca su lugar.

4. Construir el artifact canvas

Construye sobre el canvas redimensionable compartido del plugin (shared/canvas/; su README.md tiene el contrato completo). Escribe la pantalla como screen.html y la configuración del diseño como config.json en una carpeta de trabajo, luego compila:

node "${CLAUDE_PLUGIN_ROOT}/shared/canvas/build.mjs" \
  --presets "${CLAUDE_PLUGIN_ROOT}/skills/mobile/references/presets.md" \
  --config config.json --screen screen.html \
  --title "<nombre del diseño>" --out index.html

Publica index.html como artifact. Los preajustes son small 360 (Android), medium 393 y large 430 (iOS); Al rotar da cada uno en horizontal, y el pase de reajuste a 320 de ancho está en Comprobaciones.

• config.json establece title y states (p. ej., predeterminado, cargando, vacío, error). Para un diseño solo iOS coloca "initialPreset": "medium"; para iOS y Android juntos coloca "minTarget": 48 para que cada preajuste mida contra el objetivo más estricto.
• Contrato de la pantalla: un <template id="uh-screen"> con secciones [data-screen], y data-nav, data-nav-replace (pestañas), data-nav-back y data-show-state para clics. Rellena los bordes con var(--uh-safe-top|right|bottom|left), que siguen el preajuste y su rotación; declara tokens que los usen en [data-screen], ya que :host no puede verlos. Responde al tamaño con @container screen (width >= …), no @media. Texto en rem; áreas de impacto, iconos y márgenes en px, así el texto al 200% agranda las palabras, no los controles. Colores con light-dark(). El comportamiento va en window.ultrahandSetup = function (canvas) { … }.
• Partes fijas: apila todo lo fijado abajo (barra de pestañas, FAB, snackbar) en un mismo muelle para que nada se superponga, y coloca scroll-padding en [data-screen] para que el foco se desplace limpio de barras fijas [WCAG-2.4.11]. En altura compacta o texto al 200%, deja que el encabezado sea estático [WCAG-1.4.4].
• Plataforma por preajuste: small es Android, medium y large son iOS. Sigue canvas.size.platform para convenciones que difieren, como el control de retroceso, la alineación del título y el tamaño objetivo.
• Alternativas integradas: claro/oscuro, texto al 200%, el selector de estado y mostrar objetivos táctiles (44 pt, o 48 dp en preajustes Android). No construyas las tuyas. Llama a canvas.refresh() después de abrir una hoja para que la superposición de objetivos la vea.
• Diseña con unidades flexibles y los insets, no con números fijos de dispositivo, para que un diseño se adapte a cada preajuste.
• Haz clicable el flujo principal: las pestañas cambian, las filas empujan y las hojas se abren y cierran. Dibuja hojas y diálogos en la pantalla; nunca uses alert, confirm o prompt.

5. Diseñar cada preajuste

Para cada pantalla, trabaja en small, luego medium, luego large, luego cada uno en horizontal. Soluciona cada problema en el tamaño donde aparezca:

• small (360): el texto y los botones aún caben sin truncar información clave.
• large (430): el contenido no se estira en líneas largas ni deja espacio muerto.
• horizontal: la altura reducida aún muestra el campo enfocado sobre el teclado, y el área segura lateral se respeta. Verifícalo también con texto al 200%: el encabezado fijo y el muelle juntos deben dejar la mayor parte de la pantalla para el contenido.

Luego haz un pase rápido en la comprobación de reajuste a 320 de ancho.

6. Autocomprobación antes de presentar

Repasa cada elemento. Corrige cualquier falla, o nómbrala y di por qué es aceptable.

Composición (ejecuta la auditoría de composición, node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" do "${CLAUDE_PLUGIN_ROOT}/shared/composition/audit.mjs", en el tamaño más grande y más pequeño, o verifica a ojo):

• Desenfocada, la pantalla muestra las secciones previstas, y el contenido principal atrae la mirada primero. Sin punto brillante no intencionado.
• Cada sección tiene un trabajo, sus miembros agrupados por función y frecuencia, con espacios entre grupos claramente mayores que los espacios dentro de ellos.
• Cada sección tiene como máximo un elemento fuertemente enfatizado; los estados seleccionados son sutiles.
• Un estilo por rol: cuenta los estilos de control en cada sección y justifica cualquier extra. Ninguna etiqueta o estado parece un botón.
• Filas y secciones se alinean a bordes compartidos; alrededor de tres tamaños de fuente en la pantalla.
• Ningún dato se muestra dos veces, y nada en la pantalla que no sirva a una tarea aquí.
• Después de una ronda de cambios: enumera lo que añadió; la pantalla no está más ocupada de lo necesario.
• Solo valores del tema: sin colores en bruto, sin espaciado fuera de la escala de 8 puntos, sin tamaños de fuente fuera de la escala, y los componentes del inventario reutilizados en lugar de reconstruidos (shared/theme/rules.md NN-1, NN-2, NN-6, EV-4).

Componentes y plataforma:

• Los objetivos táctiles miden al menos 44 × 44 pt (iOS) o 48 × 48 dp (Android), con espaciado, y nunca menos de 24 × 24.
• La acción principal está al alcance de un pulgar; las acciones destructivas están lejos de donde descansa el pulgar.
• Nada interactivo está debajo de la barra de estado, muesca o indicador de inicio, en ninguna orientación.
• Hay de 3 a 5 pestañas de nivel superior, cada una con una etiqueta de texto, y ningún menú hamburguesa solo.
• Cada hoja tiene un botón visible de Cerrar o Cancelar y un tope claro, y las hojas nunca se apilan. Al abrir una, el foco se mueve a ella, Esc la cierra y el foco vuelve al abridor [NNG-SHEET].
• La pestaña seleccionada está marcada por más que el color, como un indicador o peso [WCAG-1.4] [M3-NAVBAR], y al eliminar algo se ofrece un deshacer táctil.
• Cada campo tiene una etiqueta encima (no un placeholder), el teclado correcto y el tipo de autocompletado, y permanece visible con el teclado levantado.
• Los errores aparecen en línea, junto al campo, y dicen cómo solucionar el problema; la entrada escrita se conserva.
• Cada gesto tiene una alternativa visible, y nada lucha con los gestos de borde del sistema.
• El texto del cuerpo es de 16–17 o mayor, y el diseño sobrevive al texto al 200% sin perder información.
• El contraste es al menos 4.5:1 para texto y 3:1 para UI en ambos modo claro y oscuro, y el color nunca es la única señal.
• Los estados de carga, vacío y error están diseñados, y la carga usa el indicador adecuado para su duración.
• El diseño funciona a 320 de ancho sin desplazamiento horizontal, y en horizontal.

7. Presentar

Comparte el enlace del artifact. En unas líneas, indica el mapa de secciones (el trabajo y el énfasis de cada sección), las decisiones clave y el principio detrás de cada una (cita la clave de la fuente), cualquier elemento de la autocomprobación que aceptaste con un motivo, cualquier adición propuesta al tema (para el skill theme), y cualquier pregunta abierta.