taste-skill-swiftui

¿Qué hace taste-skill-swiftui?

Una pantalla de aplicación construida por un modelo se parece al promedio de todas las pantallas que el modelo ha visto: un TabView de cuatro pestañas, un título grande, una Lista de tarjetas redondeadas cada una con un Símbolo SF en un cuadrado teñido, un botón azul degradado "Comenzar", una incorporación de tres páginas de símbolos, un muro de pago con un brillo. Nada en ella está mal y nada en ella fue decidido.

Este skill reemplaza esos valores predeterminados con decisiones, de cuatro maneras:

1. Un script reparte las direcciones, tú eliges entre ellas. Al pedirle que invente un aspecto, un modelo elige el valor predeterminado de la categoría cada vez. scripts/draw.mjs reparte tres de doce direcciones investigadas; tú eliges la que transmite la idea del tema, y luego reparte tipo, paleta, forma, movimiento y planos de pantalla.
2. La idea proviene del tema. Las mejores aplicaciones se construyen sobre algo tomado de la cosa en sí (su resultado, su objeto, su ritual, su artefacto impreso), no sobre el estilo.
3. Nativo primero, personalizado a propósito. Cada elemento sube una escalera (abajo). Los componentes personalizados están permitidos, y se fomentan cuando la idea lo necesita, pero deben llevar todos los comportamientos nativos.
4. Miras lo que hiciste. scripts/capture.sh fotografía la aplicación en una matriz de dispositivos, en modo claro y oscuro, con tamaño de letra predeterminado y de accesibilidad; una rúbrica de jurado evalúa las imágenes; corrige, vuelve a mirar.

Quitar los adornos es solo la mitad del trabajo. Una pantalla que perdió sus cuadrados teñidos, tarjetas y degradados y no ganó nada es superficial. La otra mitad es la sustancia: tipo más grande, campos enteros de color, imágenes reales u objetos dibujados del mundo de este tema, cada pantalla con su contenido completo, y una cosa que el usuario puede hacer que solo esta aplicación tiene.

En los comandos a continuación <skill> es la carpeta de este skill. Ejecútalos desde la raíz del proyecto; los archivos de trabajo caen en .taste-skill/. Los scripts necesitan Node 18+. capture.sh necesita Xcode y Simuladores iniciados. Cuando ~/.claude/bin/devlock exista, envuelve cada ejecución de xcodebuild y simctl en devlock run (las compilaciones paralelas han agotado el límite de procesos antes).

La escalera nativa

Sube solo hasta donde la idea lo requiera, y registra cada componente del peldaño 3 en el informe.

1. Componente del sistema, aspecto del sistema. NavigationStack, TabView, Lista, Form, Toggle, Picker, Menu, ContentUnavailableView, .sheet con topes, ShareLink, Chart, ProgressView. Gratis: Dynamic Type, VoiceOver, Reduce Motion, RTL, Liquid Glass, teclado y puntero. Úsalos para cada control cuyo trabajo sea el trabajo de la plataforma.
2. Componente del sistema, estilizado. Mismo componente, tus tokens: ButtonStyle, LabelStyle, ToggleStyle, ListRowBackground, scrollContentBackground(.hidden), tint, fontDesign, fontWidth, containerShape. Aquí es donde vive la mayor parte de una dirección.
3. Componente personalizado. Solo cuando ningún componente del sistema pueda transmitir la idea (un dial, una regla, un boleto, un escenario, un eje de línea de tiempo). Un componente personalizado debe incluir: Dynamic Type a través de @ScaledMetric/Font.custom(relativeTo:), un área de toque mínima de 44×44pt, accessibilityElement con etiqueta, valor, atributos y acciones ajustables, una ruta de Reduce Motion, hápticos a través de sensoryFeedback, Modo Oscuro, RTL (layoutDirection), estados de foco y puntero en iPad/Mac, y una vista previa para cada estado. Un control que necesita una oración de instrucciones se rediseña, no se subtitula.

Nunca reconstruyas lo que la plataforma posee: sin barra de pestañas dibujada a mano, barra de navegación, interruptor, alerta, hoja o accesorio de teclado a menos que la idea no pueda vivir sin ello. Nunca hagas un panel de desenfoque a mano; Liquid Glass proviene de las barras del sistema, las barras de herramientas y las API de vidrio del sistema solo en controles flotantes.

Web a móvil: cómo se asignan las reglas originales

Taste-skill (web)	Aquí (nativo)
Página vs pantalla de aplicación	Una aplicación es casi siempre del segundo tipo. La pantalla de primer inicio, la incorporación y el muro de pago son pantallas compuestas (siguen la ejecución). Las listas, ajustes, formularios y pantallas de detalle son pantallas de trabajo (siguen references/screens.md).
Héroe	La primera pantalla después del inicio (o la pestaña Inicio). Responde "¿qué es esto, qué hago" en tres segundos, con letra grande o un objeto grande.
Títulos de máximo dos líneas en cada ancho	Dos líneas en el tamaño predeterminado en ancho de iPhone SE y iPad, y envolviendo (nunca truncando) en tamaños de accesibilidad.
Márgenes exteriores iguales, sin secciones apiñadas	Usa los márgenes de diseño del sistema (16/20pt); iPad y paisaje tienen su propia composición (vista dividida, barra lateral, dos columnas), nunca una columna de teléfono centrada.
Piso de imágenes reales (cuatro)	Un visual real o hecho a mano por pantalla clave. Los Símbolos SF son glifos funcionales, nunca la imagen.
Escenas de desplazamiento	scrollTransition, visualEffect, matchedGeometryEffect, navigationTransition(.zoom), KeyframeAnimator, PhaseAnimator, TimelineView.
La cosa viva	El momento sorpresa: una interacción que solo esta aplicación tiene, con hápticos, que funciona con una mano.
inspect.mjs en un navegador real	capture.sh en Simuladores más lint.mjs en código fuente Swift.
Piso de movimiento	Al menos seis momentos de movimiento intencionados en el primer inicio y el flujo central; cada uno con una alternativa de Reduce Motion.
Sin vidrio	Sin tarjetas de desenfoque hechas a mano. El vidrio del sistema en el cromo del sistema está bien.
Sin monoespaciado	.monospacedDigit() solo para números alineados. Nunca design: .monospaced fuera del código.
Sin reglas finas	Los separadores de lista que dibuja el sistema están bien. Sin Divisor decorativo, sin tarjetas delineadas de 1pt.
Pie de página = cierre diseñado	La última fila de una pantalla larga, o el estado final de un flujo, está diseñada, no es espacio sobrante.

La ejecución

Haz esto en orden. Los pasos 1–5 toman unos minutos y deciden si la aplicación es buena.

1. Lee el brief y el proyecto

Encuentra lo que es real: el tema, la audiencia, la única cosa que un usuario debe hacer en el primer minuto, las plataformas y el objetivo de implementación, un sistema de diseño o tokens existentes, los activos que realmente existen (fotografía, tomas de producto, ilustraciones, metraje, una herramienta de imagen), y lo que debe sobrevivir en un rediseño (modelos, intenciones, widgets, compras, localizaciones). No planifiques alrededor de activos que no tienes. Si la solicitud es vaga, decide y declara tu lectura en una línea; pregunta solo cuando un hecho faltante bloquee el trabajo.

Inventario del tema: ocho a doce cosas que pertenecen a este cliente y a ningún competidor. Su nombre y lo que significa; los números en el brief (minutos, gramos, el precio, la racha); la restricción con la que vive (una vez al día, sin conexión, un toque); sus materiales y colores; sus rituales y horas; las cosas impresas de su mundo (un boleto, una etiqueta, un recibo, un horario, un sello de pasaporte); su sonido; su gesto físico (sacudir, soplar, presionar y mantener). La idea en el paso 4 proviene de esta lista.

2. Escribe el argumento

Enumera la aplicación como afirmaciones con su prueba, una línea por pantalla del primer inicio y el flujo central:

Pantalla: afirmación -> lo que el usuario ve o hace como prueba.

Elimina cualquier pantalla sin afirmación. Así es como evitas la secuencia estándar de pantalla de inicio, tres páginas de incorporación, solicitud de permiso, muro de pago, barra de pestañas de cuatro. La incorporación se gana su lugar solo si permite al usuario hacer la cosa central una vez.

3. Dibuja la dirección

node <skill>/scripts/draw.mjs --kind <kind> --brief "<una linea sobre el tema>" \
  --screens <roles en el orden de tu argumento> [--tone <tone>] [--have <assets>] \
  [--keep palette,type] [--platform ios|ipad|watch|mac|vision] --options 3

Esto reparte tres direcciones. Compara cada una con tu inventario: ¿cuál puede transmitir algo que solo este cliente tiene? Elige esa, no la más familiar, y escribe una línea sobre por qué. Luego reparte la hoja completa:

node <skill>/scripts/draw.mjs <mismos argumentos sin --options> --direction <id elegido>

• --kind: node <skill>/scripts/draw.mjs --list kinds (utilidad, salud, finanzas, juego, niños, social, medios, productividad, estilo de vida, creativo, comercio, otro).
• --screens: roles de --list roles (incorporación, inicio, detalle, crear, resultados, ajustes, muro de pago, vacío).
• --tone: tranquilo, audaz, cálido, técnico, juguetón, lujoso, editorial. Solo cuando el brief lo pida.
• --have: activos que existen: photography, product-photo, illustration, video, 3d. Omítelo si no hay ninguno; el dibujo entonces evita composiciones que dependan de ellos.
• --keep palette,type: cuando la marca o el sistema de diseño ya los fija. El dibujo solo reparte composición, forma y movimiento; mapeas los valores del sistema en los roles.
• --seed <n> hace que un reparto sea repetible; la hoja imprime la semilla que usó.

Adopta la hoja. No la mezcles con el diseño que habrías hecho de todos modos. Redibuja una ranura (--redraw type|palette|shape|motion|screen:<rol>|direction) solo por una razón que puedas declarar: contradice una restricción de marca, necesita un activo que no existe, o no puede contener el contenido real. Nunca redibujes para obtener algo más cómodo. Registra cada redibujo en el informe. Reimprime con --show.

Verifica la paleta contra el tema. Una paleta repartida es un conjunto de proporciones (un fondo, una tinta, un acento, campos opcionales) tanto como colores. Si lucha contra el material propio del tema, redibuja una vez, o mantén las proporciones y toma los colores del tema, y dilo.

4. Encuentra la idea

La dirección es una forma de componer. La idea es lo que hace que la aplicación pertenezca a este tema. Completa ambos espacios en blanco del tema mismo antes de construir:

En esta aplicación, [algo que pertenece al tema] se convierte en [el dispositivo que la dirección requiere].

Busca en: su resultado (lo que produce, mostrado como material), su objeto (su forma, en silueta), su nombre (letras que contienen una imagen), su lugar, su ritual (una secuencia que la aplicación realiza), su artefacto (un boleto, etiqueta, recibo), su opuesto.

La prueba del competidor: pon al competidor real más cercano en la oración. Si aún funciona, la idea pertenece a la categoría. "Limpio y moderno" no es una idea.

El momento sorpresa (la cosa viva). Dale a la aplicación una interacción que sea diferente para cada uso, hecha a partir de la idea: sopla en el micrófono y la vela parpadea; establece la dosis y lee la curva de vida media real; dobla el teléfono y el casete se reproduce. Usa contenido real, funciona con una mano con el pulgar, tiene hápticos a través de sensoryFeedback, una ruta de Reduce Motion, y nunca bloquea la tarea. Es una cosa, no un patio de juegos. Se construye en el paso 6, no se añade como movimiento al final.

5. Escribe las palabras

Escribe toda la copia (texto plano) antes de las vistas, siguiendo references/copy.md, y pon cada cadena en el Catálogo de Cadenas (Localizable.xcstrings) desde el primer commit. Cada título cabe en dos líneas en el tamaño predeterminado; una acción principal por pantalla, nombrada por lo que hace (nunca "Comenzar", "Continuar" sin nada después, "Saber más"); copia de vacío, error y permiso escrita ahora, no después. La prueba nunca se inventa: sin reseñas falsas, recuentos de usuarios, premios o prensa.

6. Constrúyelo, con calma

Construye con el movimiento desactivado en tu mente. Orden de trabajo:

1. Tokens. Palette/Theme de la hoja como colores del catálogo de activos con variantes claras y oscuras (o un enum de ShapeStyle token), un enum Typography, un enum Metrics (espaciado, radio, una regla de forma). Todo lo posterior hace referencia solo a tokens. Sin Color(red:), sin .font(.system(size: 17)) en las vistas.
2. La primera pantalla, exactamente como la describe su plano, en ancho SE, estándar, Pro Max y iPad. Haz lo grande grande y lo pequeño pequeño antes de que exista cualquier otra cosa.
3. Cada pantalla desde su plano con el contenido de este proyecto. Las pantallas vecinas no deben compartir un diseño. Lleva la idea a cada pantalla, ajustes, muro de pago y estados vacíos incluidos; el fracaso más común es un Inicio distintivo seguido de Formularios estándar.
4. Imágenes, por preferencia: las propias del proyecto; generadas (si tienes una herramienta de imagen); imágenes reales del mundo del tema de colecciones abiertas con licencias registradas (references/imagery.md); dibujadas en código (Shape, Canvas, Path) como un lenguaje gráfico plano consistente en la paleta; tipo y color solos. Símbolos SF solo como glifos funcionales.
5. El momento sorpresa del paso 4, en la pantalla donde prueba la afirmación.
6. Plenitud. Mira cada pantalla como un póster: una cosa dominante y el contenido que lleva. Una pantalla que está mayormente vacía está subconstruida. Texto corrido en la tinta completa a body o más grande.
7. El marco. Un sistema de márgenes. Cada pantalla tiene un título (título de navegación o un título de visualización grande) y cada sección de lista un encabezado que la nombre.
8. Estados y semántica. Todos ellos: carga, vacío, error, sin conexión, permiso denegado, éxito, deshabilitado, primer inicio, contenido largo, tamaños de accesibilidad, RTL. Botones reales, foco visible, etiquetas, accessibilityHint solo donde la etiqueta no pueda transmitirlo, orden de VoiceOver, Reduce Motion y Contraste Aumentado respetados.
9. Línea base de plataforma (de las reglas globales): Catálogo de Cadenas con en-US, en-GB, en-AU, en-CA y es-MX; requestReview solo después de un momento positivo, controlado por contador y días desde la instalación, una vez por versión; hápticos; Oscuro y Claro; App Intents donde la aplicación tiene una acción central.

Lee references/type.md, colour.md, layout.md y components.md cuando necesites el detalle detrás de una decisión; las leyes a continuación son la forma abreviada.

7. Puerta

node <skill>/scripts/lint.mjs <Swift files or folder>
<skill>/scripts/capture.sh <id del paquete> .taste-skill/capture   # Simuladores iniciados

lint.mjs escanea el código fuente Swift en busca de patrones prohibidos, frases hechas y líneas base faltantes (Catálogo de Cadenas, Reduce Motion, hápticos). capture.sh inicia la aplicación instalada en cada Simulador iniciado en modo claro y oscuro y en tamaños predeterminados y de accesibilidad, y guarda las capturas de pantalla. Corrige cada FALLO; trata cada ADVERTENCIA como incorrecta a menos que puedas defenderla ante un diseñador en una oración. Vuelve a ejecutar hasta que no haya FALLO. Una línea puede optar por salir con un swiftlint:disable:next en la línea anterior.