Shunqiang/skills

De Figma a Página Frontend

Resultado y alcance

Implementar el diseño seleccionado en el proyecto existente y verificar el resultado en un navegador. Normalmente, una URL de Figma es suficiente para comenzar; inferir las convenciones del proyecto a partir del repositorio. Aceptar capturas de pantalla o exportaciones proporcionadas como evidencia alternativa cuando no se pueda acceder al diseño.

Las instrucciones del usuario tienen prioridad sobre estas directrices. Preservar los cambios existentes y mantener las ediciones dentro del alcance solicitado. Identificar si la tarea es una página nueva, una actualización de página existente, una sección o un componente reutilizable antes de elegir archivos o rutas. No convertir un componente o una corrección local en una página nueva.

Restricciones principales

• Leer el código relevante del repositorio antes de editar. Reutilizar su framework, enrutador, estilo, tokens, componentes, activos y convenciones de datos cuando sea adecuado.
• Traducir la geometría del diseño en reglas de diseño. Preferir flujo normal, flex y grid; usar posicionamiento absoluto solo para superposiciones reales, decoraciones o capas flotantes. Los grupos de Figma son evidencia, no límites obligatorios de componentes.
• Reutilizar activos idénticos y componentes mapeados adecuados. Preservar imágenes y iconos distintivos en lugar de sustituir símbolos aproximados. No renderizar una sección interactiva completa como una captura de pantalla.
• Implementar el comportamiento compatible con los requisitos, prototipos o el comportamiento existente del producto. No inferir posicionamiento fijo, semántica de filtros, contratos de API o destinos de navegación solo a partir de la apariencia.
• Preservar controles semánticos, nombres accesibles, operación con teclado y comportamiento de enfoque adecuado. Excluir el marco del dispositivo, como una barra de estado del sistema operativo, a menos que se solicite.
• No afirmar paridad visual sin comparar el destino implementado con el diseño. Reportar explícitamente los requisitos bloqueados o no verificados.

Compatibilidad CSS

• Usar margin para el espaciado entre elementos flex, grid y repetidos. No usar gap, row-gap ni column-gap. Colocar el espaciado en una clase de elemento con nombre; dar al primer o último elemento una clase modificadora explícita cuando su margen difiera. No reemplazar gap con selectores como > * + *, :first-child o :last-child.
• Escribir selectores contra clases de componentes explícitas. Evitar selectores universales y combinadores de hermanos (+, ~) en estilos que puedan compilarse a WXSS. Verificar la compatibilidad de selectores de la plataforma de destino antes de usar otras pseudoclases o combinadores; no asumir que la compatibilidad CSS del navegador implica compatibilidad con WXSS.
• Para máscaras y paneles fijos, usar declaraciones explícitas top, right, bottom y left en lugar de inset. Al usar env(safe-area-inset-*), colocar un valor de respaldo simple inmediatamente antes de la declaración que use env(). Establecer box-sizing: border-box donde los anchos fijos y el relleno deban encajar.
• En Taro H5, el estilo integrado taro-button-core:active puede volver gris un botón presionado incluso cuando su clase de hover está deshabilitada. Si el diseño no tiene un cambio de color al presionar, sobrescribir los colores de fondo y texto activos para las clases de botón específicas, preservando los colores normales de cada botón. No restablecer botones globalmente ni cambiar el estilo deshabilitado.

Evidencia y decisiones

Leer design-evidence.md al recopilar o actualizar evidencia de diseño. Mantener un resumen de trabajo conciso del objetivo, las convenciones del proyecto, el mapeo de activos, las capacidades aplicables y las incertidumbres. Las notas de contexto son suficientes para tareas pequeñas; no generar un archivo de especificación a menos que sea útil o se solicite.

Clasificar las decisiones:

• Confirmado: requisitos explícitos del usuario, propiedades de diseño seleccionadas, comportamiento del prototipo o contratos de producto existentes relevantes.
• Inferido: adaptación de diseño ordinaria, ajuste y límites de componentes locales coherentes con el proyecto. Elegir la implementación razonable más pequeña y divulgar las suposiciones materiales.
• Desconocido: contratos de envío faltantes, destinos ambiguos, marcos de destino en conflicto o comportamiento comercial consecuente. Inspeccionar la evidencia disponible primero; hacer una pregunta enfocada si aún es necesario. Continuar el trabajo independiente mientras se espera una respuesta.

Un control visible por sí solo no establece su comportamiento comercial. No fingir envíos exitosos, inventar puntos finales ni sustituir silenciosamente un comportamiento simulado. Usar fixtures solo cuando la tarea o la convención de vista previa existente los admita e identificar esa limitación.

Ejecución

Seguir dependencias en lugar de repetir una secuencia fija. Para una corrección local, reutilizar la evidencia aún válida e inspeccionar la región cambiada más el comportamiento compartido afectado. Las lecturas independientes del repositorio y del diseño pueden agruparse.

1. Identificar objetivo y proyecto

Analizar la clave del archivo y el ID del nodo. Inspeccionar el tipo, las dimensiones y el contexto circundante del nodo seleccionado. Si el ID del nodo está ausente, inspeccionar los candidatos de nivel superior; seleccionar solo cuando el objetivo esté claro.

Usar búsquedas y lecturas dirigidas para establecer:

• instrucciones aplicables del repositorio y cambios actuales;
• gestor de paquetes, comandos de desarrollo y verificación;
• archivos de destino probables y la implementación existente más cercana;
• enrutador, estilos, tokens, fuentes, manejo de viewport/unidades y convenciones de componentes;
• mapeos de diseño a código existentes y activos cuando estén disponibles.

Para trabajo en página existente o componente, preservar su punto de entrada. Para una página nueva, seguir la familia de rutas existente y las convenciones de parámetros, verificando conflictos. Usar el nombre del marco solo como una sugerencia de nombre de respaldo; no imponer una ruta de detalle genérica.

2. Adquirir evidencia de diseño suficiente

Preferir las herramientas disponibles de Figma para metadatos, capturas de pantalla, variables, mapeos de componentes y activos. Seguir los requisitos previos de habilidad específicos de la herramienta requerida antes de usar esas herramientas. Si falla el acceso, probar con un navegador autenticado disponible, luego capturas de pantalla o exportaciones proporcionadas. No usar la búsqueda web como sustituto del diseño real.

Comenzar con la captura de pantalla del objetivo y la visión general estructural, luego obtener detalles de los subárboles relevantes. Inspeccionar el contenido debajo del pliegue. No recuperar repetidamente todo el archivo o marcos no relacionados. Registrar las medidas o estados no disponibles como incertidumbre en lugar de hechos exactos.

3. Mapear e implementar

Mapear el diseño en módulos significativos, eligiendo componentes existentes donde su comportamiento y apariencia se ajusten. Extraer un componente cuando la reutilización, el comportamiento independiente o la complejidad lo justifiquen; no dividir cada envoltorio ni crear un sistema de diseño para una página.

Resolver fuentes y activos principales temprano. Preservar la relación de aspecto del activo, la transparencia y la resolución adecuada; usar convenciones de almacenamiento del repositorio y nombres de archivo semánticos. Verificar que los activos en tiempo de ejecución se carguen desde una ubicación duradera compatible con el proyecto.

Derivar el tamaño fluido, los anchos máximos, el ajuste y los puntos de interrupción de las variantes proporcionadas y el comportamiento existente del proyecto. Con un único tamaño de diseño, implementar una adaptación conservadora y distinguirla de un diseño receptivo especificado por el diseñador. Probar la plataforma solicitada; no crear un rediseño de escritorio o móvil no solicitado.

Para proyectos Taro que comparten estilos entre compilaciones H5 y mini-programas, inspeccionar el WXSS generado así como la hoja de estilo fuente. Verificar el espaciado y los estados presionados en cada tiempo de ejecución solicitado cuando esté disponible.

Habilitar solo las ramas de comportamiento relevantes:

• Navegación: usar destinos establecidos y comportamiento de enrutamiento.
• Formularios y colecciones: usar contratos de datos existentes; implementar los estados requeridos de validación, carga, vacío, error y éxito.
• Pestañas y filtros: establecer la propiedad del estado y la semántica de selección a partir de la evidencia. El comportamiento de borrador/confirmación aplica solo cuando sea compatible.
• Tablas: preservar la alineación y los bordes mostrados; proporcionar desbordamiento adecuado al viewport de destino.
• Superposiciones o UI fija: leer overlays-and-sticky.md.
• Movimiento o medios: reproducir el comportamiento confirmado y manejar la carga y el movimiento reducido cuando corresponda.

4. Verificar e iterar

Reutilizar un servidor en ejecución adecuado, o iniciar el comando de desarrollo documentado en un puerto disponible. Usar una superficie de automatización de navegador disponible, prefiriendo el navegador integrado en la aplicación cuando sea adecuado, luego un navegador externo autenticado o las herramientas de navegador del proyecto. Inspeccionar la ruta relevante o la vista previa del componente existente.

Leer acceptance-checklist.md para comparación visual, verificaciones de interacción aplicables y criterios de finalización. Corregir grandes diferencias estructurales antes del pulido local. Después de cada cambio, verificar la región afectada; realizar una verificación final de todo el objetivo.

Ejecutar las verificaciones relevantes del repositorio, inspeccionar el diff final y distinguir las fallas preexistentes de las introducidas. Evitar agregar dependencias o refactorizaciones amplias solo para realizar la verificación. Preservar las sesiones de servidor preexistentes y hacer que el estado de cualquier servidor iniciado para esta tarea sea intencional.

Recuperación y finalización

Si falla el acceso o la verificación en tiempo de ejecución, inspeccionar el error concreto y probar una alternativa relevante disponible. Dejar de repetir un fallo sin cambios sin nueva evidencia. Continuar el trabajo que se pueda completar de forma independiente, luego reportar el bloqueador exacto, lo que se implementó y lo que queda sin verificar. Las herramientas o credenciales faltantes no son evidencia de verificación exitosa.

Completar cuando el objetivo solicitado esté implementado, las verificaciones aplicables pasen y no quede ningún defecto requerido conocido. Las diferencias menores de renderizado pueden documentarse; los errores de diseño no resueltos, el comportamiento requerido faltante o las verificaciones de navegador bloqueadas no deben presentarse como finalización completa.

Reportar de manera concisa:

• objetivo implementado y punto de entrada, incluyendo una ruta solo cuando corresponda;
• cambios significativos de comportamiento y componentes;
• ubicación de vista previa y verificaciones realmente realizadas;
• suposiciones materiales, diferencias no resueltas o bloqueadores.