Justin Figma Design (/jfd)

¿Qué hace jfd)?

Este espacio de trabajo es un entorno de colaboración centrado en Figma, no un código base de aplicación. Este skill es la capa de orquestación: memoria del workspace, el flujo de trabajo de Figma Console, disciplina del sistema de diseño y control de calidad visual basado en evidencia. No generes React, HTML o CSS a menos que el usuario solicite explícitamente convertir diseño en código.

MCP complementario requerido

Todo el trabajo en Figma se ejecuta sobre Figma Console MCP (user-figma-console): figma_execute para inspeccionar y mutar, figma_take_screenshot para obtener evidencia, figma_get_status y figma_reconnect para la conexión Desktop Bridge. El trabajo de escritura requiere el servidor local/NPX con Desktop Bridge conectado; el modo remoto alojado es de solo lectura. Lee references/figma-execute.md antes de escribir cualquier script, y el archivo del workspace docs/tools/figma-console.md (en la raíz del workspace) para detalles de conexión. No trates /jfd como un editor Figma independiente sin esa conexión MCP.

Resuelve hechos desde el diseño, no desde este skill

Este skill proporciona procedimientos, no hechos. Los tamaños de dispositivo, fuentes, espaciados y preferencias de estilo cambian con el tiempo; el archivo de destino siempre está actualizado. Resuelve cualquier valor necesario (una dimensión, fuente, paso de espaciado, color, nombre o convención) en este orden:

1. El archivo de destino. Mide el frame, texto, token o componente real.
2. La familia. frames, estados y pantallas hermanos en la misma sección.
3. Memoria del workspace. Los archivos docs/files/<alias>/design.md y docs/preferences.md del proyecto, respetando sus fechas de "Última verificación".
4. El usuario o una consulta actual. Pregunta, o consulta las guías de plataforma actuales. Nunca confíes en tamaños de dispositivo recordados o valores antiguos.
5. Escríbelo. Registra el valor resuelto con la fecha de hoy en el design.md de destino para que la próxima sesión pueda confiar en él.

Nunca resuelvas un valor de proyecto a partir del texto de este skill.

Dos flujos de trabajo

• Editar un archivo existente (por defecto): hay algo que medir. Sigue el bucle completo a continuación, y nunca asumas un tamaño de frame raíz: mide la raíz real de la familia que se está editando.
• Comenzar desde cero: no existe nada que medir, por lo que el orden de resolución se ejecuta en los pasos 3–5. Lee references/starting-from-scratch.md. Confirma el tamaño del frame raíz, la tipografía y la compatibilidad con temas con el usuario antes de construir, y luego crea el archivo design.md inmediatamente para que cada sesión posterior pueda medir en lugar de adivinar.

Inicializar un workspace vacío

Usa el modo init cuando el workspace no tenga docs/preferences.md y docs/FILES.md. Init es un andamio local e idempotente; nunca abre Figma, llama al MCP ni muta un canvas.

1. Trata jfd init igual que /jfd init cuando el anfitrión no tenga alias de barra.
2. Enumera las rutas de andamio faltantes antes de escribir. En un workspace no vacío, pide confirmación primero. Nunca sobrescribas un archivo, directorio, enlace simbólico o instalación de skill existente.
3. Copia solo los archivos faltantes de assets/templates/ de este skill.
4. Instala una copia faltante del skill en .agents/skills/justin-figma-design/ (canónico) y en .cursor/skills/justin-figma-design/ cuando sea apropiado.
5. Opcionalmente, ejecuta scripts/init_project.py (Python 3, solo stdlib) para un pase masivo; las herramientas de archivo del agente siguen siendo la ruta principal.
6. Verifica el andamio, luego pide un enlace de Figma o clave de archivo. Nunca inventes credenciales ni datos de archivo.

Detalles: references/getting-started.md.

Elige el modo de operación

Non-YOLO es el valor por defecto.

• Non-YOLO para trabajo de producción: patrones compartidos, pantallas, componentes, variables, temas, cambios responsivos y cualquier ámbito no explícitamente desechable.
• YOLO solo cuando el usuario dice explícitamente "YOLO", "demo rápida", "prototipo rápido" o equivalente, y el ámbito es una sola board o estado nombrado.
• "Hacer un componente", "actualizar una librería", "soportar modo claro y oscuro" o un cambio de chrome compartido nunca es YOLO solo porque sea pequeño.
• Mantente en modo plan hasta que el usuario solicite claramente implementar o ejecutar.

YOLO reduce la sobrecarga de librerías; no elimina la seguridad ni el QA visual. Escala a Non-YOLO al descubrir chrome compartido, un patrón reutilizable, múltiples estados relacionados, propagación claro/oscuro o responsiva, un cambio de componente maestro, una refactorización de Auto Layout, un cambio de regla de negocio o una segunda board. Enrutador completo y listas de verificación: references/modes-and-workflow.md.

Antes de cualquier mutación en Figma

1. Lee docs/preferences.md y docs/FILES.md en la raíz del workspace.
2. Resuelve el alias del archivo de destino y lee su docs/files/<alias>/design.md; lee screens.md para trabajo de pantalla, flujo o superficie compuesta.
3. Lee la nota de sesión relevante más reciente. El design.md vivo y la autoridad actual tienen prioridad sobre las notas históricas obsoletas.
4. Confirma el archivo Figma, página, sección/frame y autoridad activos. Vuelve a buscar IDs de nodo, componentes, variables y estilos en el archivo conectado; los IDs de sesiones anteriores son evidencia obsoleta, no autorización.
5. Inventaria toda la familia del mismo frame/estado antes de un cambio compartido: claro/oscuro, expandido/colapsado, rutas activas anidadas, superposiciones, variantes responsivas y estados eliminados intencionalmente.
6. Mide los frames raíz de la familia que se está editando. Nunca asumas un tamaño de dispositivo.
7. Antes de la mutación de texto, inspecciona los segmentos de fuente con estilo y carga las fuentes actuales. Elige cualquier fuente de reemplazo siguiendo el orden de resolución: texto medido, luego design.md, luego el usuario; nunca desde este skill.

Si el archivo de destino no tiene design.md, completa primero una línea base de investigación de solo lectura. Si no se puede verificar el archivo activo o la autoridad, detente y pregunta.

Gráficos comunes

Antes de colocar iconos o imágenes importadas, lee docs/assets/README.md y docs/assets/icons.md en la raíz del workspace. Prefiere los componentes de archivo existentes y las fuentes de iconos aprobadas del proyecto; inspecciona los límites del vector, el tamaño y el contraste del tema antes de aceptar un nuevo gráfico. Los avatares son solo proporcionados por el usuario; nunca los generes.

Contrato Non-YOLO

• Busca primero instancias/componentes locales autorizados, luego librerías habilitadas, luego búsqueda más amplia en librerías. Crea solo después de documentar la brecha.
• Construye el sistema de diseño mínimo coherente para el ámbito aprobado: variables y modos primero, luego estilos y componentes, luego instancias de pantalla.
• Usa variantes para estados estructurales/visuales y propiedades de componente para flexibilidad de contenido. Prefiere instancias, intercambios de instancias y envoltorios controlados sobre redibujos desprendidos.
• Haz que la intención del diseño sea legible: nombres semánticos, jerarquía significativa, Auto Layout donde los hijos se relacionan, enlaces de tokens, descripciones de componentes y comportamiento de accesibilidad/estado documentado.
• Trata Claro/Oscuro como una matriz de modo de variable, no dos pantallas codificadas. Ver references/variables-and-theming.md.
• Aplica cambios compartidos a la familia de pantallas relacionadas completa en un solo pase, luego haz QA de cada miembro. Una corrección de un solo frame no está completa mientras los hermanos estén desactualizados.

Lee references/components-and-design-system.md y references/layout-and-autolayout.md antes de trabajo complejo.

Reglas de layout

Elige Hug, Fill, Fixed, y min/max de forma independiente por eje: Hug para pilas y controles impulsados por contenido; Fill solo para un hijo con espacio disponible significativo en un padre Auto Layout; Fixed para límites estructurales intencionales (raíces de pantalla medidas, cajas de iconos, CTA, shells calibrados); min/max para límites responsivos aprobados. Codifica relaciones con Auto Layout anidado, padding y gap: nunca frames espaciadores invisibles que preserven coordenadas antiguas. Mantén capas absolutas / Ignorar auto-layout solo para superposiciones justificadas, chrome, decoración o excepciones documentadas en el design.md de destino. Después de redimensionar un contenedor, audita los descendientes que poseen ancho; un padre más ancho no es un reflujo completo. Detalles: references/layout-and-autolayout.md.

Ejecuta y verifica

Inspecciona, ejecuta un pequeño figma_execute específico, devuelve cada ID mutado y geometría útil, y luego captura una captura de pantalla inmediatamente con figma_take_screenshot. Mantén las escrituras y capturas de pantalla secuenciales cuando el enrutamiento dependa del archivo activo. El QA combina estructura medida con evidencia visual: captura, según corresponda: (1) un recorte de componente enfocado, (2) la board completa, (3) la familia relacionada o descripción general de la sección. Verifica bordes compartidos, espaciado, recorte, desbordamiento, comportamiento de copia larga, límites de icono/vector, contraste, tipografía, controles ocultos, estado semántico, paridad de estado relacionado, valores codificados, enlaces no resueltos y resolución Claro/Oscuro. Usa diseños Figma Check cuando estén disponibles; de lo contrario, ejecuta comprobaciones estructurales y manuales equivalentes.

Trata un figma_execute fallido como potencialmente parcial hasta que se inspeccione el destino; nunca vuelvas a ejecutar ciegamente un script de creación o re-parentación fallido. Contrato de recuperación: references/figma-execute.md. Listas de verificación completas: references/qa-and-recovery.md.

Cierre

• Captura capturas de pantalla finales de cada board mutado y miembro de familia requerido.
• Registra excepciones intencionales, marcadores de posición, problemas no resueltos y límites de alcance.
• Actualiza el design.md y screens.md de destino cuando la autoridad, componentes, variables, pantallas, tamaños raíz o desviaciones hayan cambiado, incluido cualquier valor resuelto durante la sesión.
• Escribe una nota con fecha bajo docs/sessions/ para trabajo significativo.

Respeta las protecciones documentadas del archivo de destino en su design.md: originales bloqueados o protegidos, estilos o estados que deben permanecer eliminados, copia y lenguaje que deben conservarse. Nunca almacenes credenciales o tokens privados en la memoria del proyecto.

Para orientación externa detrás de este skill, lee references/research-sources.md.