Linear, GitHub, Figma y Slack: una capa de inteligencia
Deja el copy-paste entre Linear, GitHub, Figma y Slack. Conecta tus herramientas en una capa de inteligencia que mantiene el contexto activo.
By Ellis Keane · 2026-03-13
Cuatro herramientas, seis conexiones posibles por pares, seis procesos OAuth separados, seis opiniones distintas sobre lo que significa estar «conectado». La combinatoria: el regalo que no para de dar.
Lo extraño no es que integrar Linear, GitHub, Figma y Slack requiera tanto proceso. Lo extraño es que todos hemos acordado fingir que el resultado es un sistema conectado – aunque ninguna integración sabe nada de las demás. Configuras cada par, verificas los webhooks y lo llamas listo. Es como construir seis puentes separados entre cuatro islas y llamarlo red de carreteras.
Es como construir seis puentes separados entre cuatro islas y llamarlo red de carreteras. – Chris Calo
Esta guía recorre cada par con los pasos de configuración reales, lo que cada conexión te aporta y dónde están las costuras arquitectónicas. Si ya has configurado algunos de estos, salta a la lista de verificación y a la tabla de análisis de brechas – esas son las partes que la mayoría de las guías omiten.
El par que realmente funciona: Linear y GitHub
Esta es la integración nativa más sólida del grupo, y merece la pena configurarla correctamente.
Abre Linear Settings, navega a Integraciones y autoriza la app de GitHub – seleccionarás qué organización y repositorios conectar. Desde ahí, configura la creación automática de ramas para que al iniciar un issue de Linear se cree una rama con el ID del issue en el nombre. Configura las automatizaciones de estado: PR abierto mueve el issue a «In Progress», PR fusionado lo mueve a «Done» (o como se llamen tus estados de flujo de trabajo – Linear te permite mapearlos). Opcionalmente activa la vinculación de commits, para que los commits que referencian un ID de issue aparezcan en el ticket de Linear.
Lo que esto te da es una sincronización bidireccional real. La actividad de GitHub aparece en los tickets de Linear, las transiciones de estado ocurren automáticamente al fusionar, y los nombres de las ramas llevan el contexto del issue. Si todo tu flujo de trabajo viviera solo en estas dos herramientas, estarías en buena posición.
Lo que no te da es ninguna conciencia de Figma o Slack. Un PR vinculado a un issue de Linear no tiene idea de que la funcionalidad que implementa fue discutida en un hilo de Slack el martes pasado, ni de que el diseñador dejó tres comentarios sin resolver en el mockup de Figma. Sólido dentro del par, completamente ciego fuera de él.
Donde Slack se encuentra con Linear (y es mejor de lo que piensas)
Instala la app de Linear desde el Directorio de Apps de Slack, luego configura qué equipos publican notificaciones en qué canales de Slack – la mayoría de los equipos usan un canal por equipo de Linear (#eng-notifications, #design-notifications, etc.). Activa la creación de issues desde mensajes de Slack mediante el menú de acciones del mensaje (los tres puntos, luego «Create Linear issue»), y el hilo de Slack queda vinculado al ticket. La sincronización de hilos también está disponible si quieres que las respuestas en el issue de Linear aparezcan en Slack y viceversa – es opt-in por equipo.
El resultado es más capaz de lo que la mayoría le da crédito. Puedes triagear directamente desde Slack sin cambio de contexto a Linear, y la vinculación de hilos significa que hay un rastro de vuelta a la conversación original.
La brecha es la correlación. Si un hilo de Slack lleva a un ticket de Linear, que lleva a un PR, que lleva a feedback de Figma – la integración de Slack solo conoce el primer salto. El hilo que inició toda la cadena no tiene ningún enlace con la revisión de diseño que ocurre tres herramientas más allá. (Podrías mantener esto manualmente, claro. Y si disfrutas ese tipo de cosas, no te lo impediré.)
El pipeline de Figma a Slack: mayormente cosmético
Existe una app de Figma dedicada para Slack que gestiona el despliegue de enlaces, las notificaciones de comentarios y (en teoría) la posibilidad de responder a comentarios de Figma desde Slack – aunque exactamente qué funciones están disponibles depende de tu plan de Figma y la configuración del administrador del workspace. Instálala desde el Directorio de Apps de Slack, luego configura qué equipos de Figma envían notificaciones a qué canales. Por separado, pegar una URL de Figma en cualquier canal de Slack la despliega con una vista previa enriquecida que muestra el diseño – eso funciona mediante el manejo nativo de URLs de Slack, sin necesidad de app.
Lo que obtienes es visibilidad. Cuando alguien pega un enlace de Figma en Slack, el equipo puede ver el diseño en línea. Las notificaciones de comentarios mantienen el feedback de diseño en tu radar.
Lo que no obtienes es bidireccionalidad. No hay un enlace de vuelta desde un comentario de Figma al hilo de Slack que motivó el cambio de diseño. Si tu diseñador deja un comentario en un frame diciendo «el padding está mal según la discusión en #product», esa referencia a #product es solo texto plano – Figma no sabe que es un canal de Slack, y Slack no sabe que un comentario de Figma está referenciando uno de sus hilos. Dos herramientas, ambas alfabetizadas, ninguna lee la letra del otro.
Figma en Linear: un marco de imagen, no un cable en vivo
Abre cualquier issue de Linear, usa el menú de adjuntos para añadir un embed de Figma y pega la URL del frame. Se renderiza en línea – puedes ver el diseño sin salir de Linear. Figma también tiene un plugin de Linear que te permite vincular frames a issues desde el propio Figma.
Las referencias de diseño visibles junto a los tickets son una mejora real respecto a la era del copy-paste (días apasionantes, aquellos). Pero Linear incrusta el frame sin monitorizarlo. Si alguien deja feedback en el lado de Figma, el ticket de Linear no tiene ni idea. Sin alertas por comentarios sin responder, sin conciencia de que el diseño vinculado ha cambiado desde que se incrustó. Es una referencia, no una conexión.
Los pares que nadie construye
Habrás notado que me salté Figma + GitHub y GitHub + Slack. No hay integración nativa para Figma y GitHub (viven en universos distintos), y aunque existe la app de Slack de GitHub, son principalmente notificaciones de CI/despliegue – útiles para saber que tu build falló, no para rastrear un trabajo a través de herramientas.
Estos pares ausentes no son descuidos. Cada empresa de herramientas construye conectores hacia las herramientas que sus usuarios solicitan más, y el flujo de trabajo entre un frame de Figma y un commit de GitHub siempre pasa primero por algo más – normalmente Linear. La economía de integraciones funciona por demanda, y nadie exige una línea directa entre anotaciones de diseño y git diffs.
Verifica que realmente funciona
Una vez que todo esté configurado, confirma que funciona (porque «instalado» y «funcionando» son, en este sector, dos cosas muy distintas):
- Linear + GitHub: Crea una rama desde un issue de Linear. Abre un PR y fusiónalo. El issue de Linear debería hacer la transición automática a tu estado «done» configurado.
- Slack + Linear: Escribe
/linear en Slack y crea un issue de prueba. Confirma que aparece en Linear con el hilo de Slack vinculado.
- Figma + Slack: Pega una URL de un frame de Figma en un canal de Slack. Deberías ver una vista previa enriquecida con el diseño incrustado, no un enlace desnudo.
- Figma + Linear: Abre un issue de Linear y añade un embed de Figma. Confirma que el frame se renderiza en línea, no como un marcador de posición roto.
Si alguno de estos falla, casi siempre son permisos – la integración necesita acceso al proyecto específico de Figma, workspace de Slack u organización de GitHub que estás usando. Comprueba los scopes de OAuth y, si tienes un plan Enterprise, verifica si un administrador necesita aprobar la app.
Lo que realmente obtienes al integrar Linear, GitHub, Figma y Slack
Este es el panorama honesto tras configurar todas las integraciones nativas disponibles:
| Qué funciona | Qué sigue faltando | |--------------|-------------------| | PRs de GitHub vinculados a issues de Linear | Comentarios de Figma correlacionados con PRs y tickets | | Actualizaciones de Linear publicadas en Slack | Decisiones de Slack vinculadas a las tareas que afectan | | Vistas previas de Figma en mensajes de Slack | Búsqueda entre herramientas («encuentra todo sobre el rediseño de nav») | | Frames de Figma incrustados en Linear | Una vista unificada de cualquier trabajo en las cuatro herramientas | | Automatizaciones de estado al fusionar PR | Conciencia de que un comentario de Figma y un hilo de Slack son sobre la misma funcionalidad |
La columna derecha no es una solicitud de funcionalidad para ninguna herramienta individual. Es la brecha entre la integración por pares y la correlación entre herramientas – la capacidad de decir «estas doce señales en cuatro herramientas forman parte del mismo trabajo». Ninguna empresa de herramientas individual tiene incentivo para construir esto, porque requiere comprender las relaciones entre los productos de sus competidores. Lo cual es, si lo piensas, un fracaso de mercado deliciosamente perverso.
Por qué Zapier no te salvará aquí
El instinto es recurrir a Zapier o Make. Configurar algunas automatizaciones, canalizar datos entre herramientas, resuelto. Y para flujos predecibles de dos herramientas – «cuando se abre un PR, publica en #engineering» – eso es un Zap de diez minutos, es fiable, y lo recomendaría.
Pero en el momento en que necesitas contexto que abarca tres o cuatro herramientas, estás encadenando automatizaciones donde un Zap dispara un webhook que activa un escenario de Make que publica en Slack. Cuando algo se rompe (normalmente una expiración de token, normalmente en un momento inoportuno), estás rastreando registros de ejecución en tres plataformas para encontrar qué paso se tragó silenciosamente el payload.
El problema más profundo es arquitectónico: las herramientas de automatización mueven datos pero no pueden correlacionarlos. Un Zap no sabe que el mensaje de Slack que reenvió trata de la misma funcionalidad que el comentario de Figma y el PR de GitHub. No puede saberlo – los payloads de webhook de Figma no llevan IDs de issues de Linear, los eventos de PR de GitHub no referencian marcas de tiempo de hilos de Slack, y la Events API de Slack no tiene concepto de un frame de Figma. No hay una clave foránea compartida entre estas herramientas. Es fontanería sin comprensión.
Las integraciones nativas gestionan pares de herramientas. Las capas de automatización gestionan el movimiento de datos. Ninguna gestiona la correlación entre herramientas – entender que una decisión de diseño, un cambio de código, una conversación y una tarea forman parte del mismo trabajo.
Lo que la correlación realmente requiere
Llenar esta brecha requiere algo que se sitúe por encima de tus herramientas individuales y construya un mapa de las relaciones entre sus señales. No solo «este PR está vinculado a este issue», sino «este comentario de Figma del martes, este hilo de Slack de la semana pasada, este ticket de Linear y estos tres commits forman parte de la misma funcionalidad».
Eso significa ingerir señales de las cuatro APIs, clasificar cada una (¿se trata de un trabajo existente? ¿una nueva tarea? ¿ruido?) y vincular señales relacionadas en un grafo. La diferencia práctica: en lugar de comprobar cuatro herramientas para entender el estado de una funcionalidad, compruebas un solo lugar. En lugar de esperar que alguien haya notado ese comentario de Figma, aparece junto al código y la conversación relacionados.
Esto es difícil de construir. Lo sé porque lo estamos construyendo. Pero los requisitos arquitectónicos merecen entenderse aunque nunca construyas nada – explican por qué el enfoque por pares tiene un techo, y por qué «añade otro Zap» deja de funcionar a partir de cierta escala.
Recibe inteligencia de señales directamente en tu bandeja de entrada.
Q: ¿Conecta Sugarbug Linear, GitHub, Figma y Slack automáticamente? A: Sí. Sugarbug se conecta a los cuatro a través de la API y construye un grafo de conocimiento entre ellos. Cuando un comentario de Figma se relaciona con un issue de Linear que tiene un PR de GitHub vinculado y discutido en Slack, Sugarbug infiere esa relación automáticamente – y puedes confirmar o corregir cualquier enlace que detecte mal.
Q: ¿En qué se diferencia Sugarbug de usar Zapier para conectar estas herramientas? A: Zapier mueve datos entre herramientas mediante automatizaciones de acción-disparador – si ocurre X, haz Y. Sugarbug construye un grafo de conocimiento que entiende las relaciones entre tareas, código, diseños y conversaciones. En lugar de mantener docenas de Zaps, Sugarbug muestra el contexto entre herramientas cuando lo necesitas.
Q: ¿Puedo conectar Linear y GitHub sin Sugarbug? A: Por supuesto – la integración nativa de GitHub en Linear sincroniza PRs, ramas y transiciones de estado. Es realmente sólida para ese par. Pero añade comentarios de Figma, hilos de Slack y documentos de Notion, y vuelves a conectar los puntos manualmente entre herramientas.
Q: ¿Qué ocurre con mis integraciones existentes si añado Sugarbug? A: Nada cambia. Sugarbug convive con tus integraciones nativas, no las reemplaza. Tu sincronización Linear-GitHub sigue funcionando. Sugarbug añade la capa entre herramientas encima – conectando una decisión de Slack con el mockup de Figma, el ticket de Linear y el PR.
Q: ¿Requiere Sugarbug que mi equipo cambie cómo usa sus herramientas? A: No. Sugarbug observa las señales que tus herramientas ya producen y las conecta en segundo plano. Tu equipo sigue usando Linear, GitHub, Figma y Slack como siempre – la capa de contexto funciona sin cambiar el flujo de trabajo de nadie.