Convierte un mensaje de Slack en una issue de GitHub, y en una corrección
Describe un error en Slack con tus palabras. Zero escribe la issue de GitHub y la asigna, y cuando la causa está en un solo componente abre un pull request con la corrección y una prueba de regresión para que la revises.
Lo que entrega Zero: del mensaje de Slack a una corrección en revisión
Un hilo real del canal #bug-report del equipo de vm0, tal como ocurrió. Alguien del equipo pegó el reporte de un cliente y pidió el arreglo. Cuatro minutos después Zero había creado la issue en GitHub con su diagnóstico. Catorce minutos después del primer mensaje ya había abierto el pull request y publicado el enlace de vista previa. Abajo están las dos capturas: el hilo donde empezó y el pull request que escribió Zero. Ambos son públicos: puedes leer la issue, el diff y la revisión por tu cuenta.
Qué pasó en el hilo
Alguien del equipo reportó en #bug-report un fallo de maquetación de la PWA que había visto un cliente y adjuntó las capturas. Zero leyó el hilo, lo atribuyó a una barra superior renderizada sin el safe area inset de iOS y creó la issue #11708 con etiquetas y su razonamiento. Cuando en el hilo se pidió el arreglo, Zero cambió un solo archivo (una altura mínima y un padding de safe area en la barra superior móvil), abrió el pull request #11709 con el enlace de vista previa y se detuvo ahí. La revisión y el merge los hizo una persona.
- Del mensaje a la issue
- 4 minissue #11708, etiquetada bug y PWA
- Del mensaje al pull request
- 14 minPR #11709 con enlace de vista previa
- Archivos que cambió el arreglo
- 1merge hecho por una persona, no por Zero
¿Qué significa crear una issue de GitHub desde Slack?
Crear una issue de GitHub desde Slack significa convertir un error que alguien describió en una conversación en una issue bien estructurada en tu repositorio, sin que nadie tenga que salir del hilo para volver a escribirlo. La parte difícil nunca fue la llamada a la API: es redactar un título claro, separar los pasos para reproducir del comportamiento esperado, elegir etiquetas, fijar una prioridad y dar con la persona adecuada. Zero hace ese trabajo. Lee el mensaje de Slack y las respuestas que lo rodean, escribe el cuerpo de la issue, aplica etiquetas y una prioridad que puede justificar, resuelve la persona asignada emparejando el nombre visible de Slack con un usuario de GitHub y publica el enlace de la issue en el mismo hilo para que quien reportó pueda comprobarlo de un vistazo.
Por qué los reportes de errores se pierden en los hilos de Slack
Alguien detecta un error durante una demo, o un cliente escribe un sábado. El camino de siempre es largo: abrir GitHub, buscar el repositorio, escribir una issue con formato, asignar a alguien y luego esperar a que esa persona la tome, lea el código y escriba la corrección. Un cambio de diez minutos se convierte en una ida y vuelta de varios días entre tres personas, y la mitad de los reportes nunca sale del hilo. En vez de eso lo describes en Slack. Zero crea la issue con pasos para reproducir, etiquetas y responsable, y donde la causa está acotada sigue y abre un pull request con la corrección y una prueba. Tú revisas y publicas.
Cómo crea Zero una issue de GitHub desde Slack
Paso 1: Conecta tus herramientas
Paso 2: Pregúntale a Zero
Paso 3: Llévalo más lejos
Las integraciones de Slack y GitHub detrás del flujo
Es una integración de Slack con GitHub con un agente en medio: Zero lee la conversación en Slack y escribe el registro en GitHub. Cada conector se concede por separado y se limita a lo que el flujo usa realmente, así que leer un canal nunca implica acceso de escritura a tus repositorios.
Integración con Slack: la conversación que lee Zero
ObligatorioZero lee el mensaje que le indicas y las respuestas a su alrededor, de modo que el contexto que llegó tres mensajes después también acaba en la issue. Recoge las capturas adjuntas y las traslada, lee el nombre visible de quien reporta para resolver el responsable y conserva el enlace permanente del mensaje, así cada issue apunta a donde empezó el reporte. Escribe una sola cosa: una respuesta en el mismo hilo con el número y el enlace de la issue. Zero no publica en otros canales, no envía mensajes directos ni edita los mensajes de nadie.
Integración con GitHub: la issue que crea Zero
ObligatorioZero crea la issue en el repositorio que indiques, con un título redactado a partir del reporte y no una copia del mensaje en bruto, con descripción, pasos para reproducir, comportamiento esperado y el área afectada cuando el hilo la menciona. Aplica las etiquetas que definas o las infiere del texto, fija una prioridad que explica y asigna al responsable. Antes de crearla busca en las issues abiertas el mismo síntoma y comenta en la existente cuando encuentra una coincidencia. Cuando además puede corregir el error, sube una rama y abre un pull request que cierra la issue y pide revisión. El acceso de escritura se limita a los repositorios que concedas, y esa es toda la superficie: issues, comentarios y pull requests abiertos para revisión. Zero no fusiona, no hace force push ni toca los ajustes del repositorio.
Zero frente a la app de GitHub para Slack y a un creador de automatizaciones
Llevar un error de un mensaje de Slack a GitHub tiene tres partes: capturar el reporte, escribir una issue utilizable y encaminarla a un responsable. Las opciones existentes resuelven una cada una.
La app de GitHub para Slack
Escribir /github abre un cuadro donde rellenas tú el título, el cuerpo, las etiquetas y el responsable. Ahorra el viaje al navegador, pero sigues siendo tú quien escribe la issue, y un formulario en mitad de una conversación es justo la fricción que hace que la gente diga «ya lo reporto luego».
Un creador de automatizaciones
Una herramienta sin código puede copiar un mensaje de Slack en una issue nueva con un disparador. Lo que copia es el mensaje en bruto, así que la issue hereda lo que a quien reportó le salió escribir, y las reglas de etiquetas, prioridad, asignación y duplicados las defines y mantienes tú, canal por canal.
El flujo de Slack a GitHub de Zero
Zero lee el hilo y escribe la issue: un título de verdad, pasos para reproducir separados del comportamiento esperado, etiquetas y una prioridad que puede justificar, y un responsable emparejado desde el nombre visible de quien reporta. Cuando la causa está contenida en un solo componente sigue adelante y abre un pull request con la corrección y una prueba de regresión, vinculado a la issue y a la espera de tu revisión. Comprueba antes las issues abiertas y comenta en un duplicado en lugar de crearlo, y responde en el hilo con el enlace.
Consejos para mejores resultados
Preguntas frecuentes
¿Cómo se crea una issue de GitHub desde un mensaje de Slack?
Conecta Slack y GitHub a Zero, describe el error en el canal y menciona a Zero. Lee el mensaje y las respuestas cercanas, escribe una issue con título, pasos para reproducir, comportamiento esperado, etiquetas y prioridad, la crea en el repositorio que indicaste, asigna un responsable y responde en el hilo con el número y el enlace. No rellenas ningún formulario.
¿En qué se diferencia de la app de GitHub para Slack?
La app de GitHub te da un cuadro para rellenar: el título, el cuerpo, las etiquetas y el responsable los escribes tú. Zero los escribe a partir de la conversación, comprueba si ya existe una issue con el mismo síntoma antes de crearla y puede recorrer un canal entero de forma programada en vez de mensaje a mensaje.
¿Zero solo crea la issue o también puede corregir el error?
Ambas cosas, y te dice cuál hizo y por qué. Zero siempre crea la issue. Cuando el hilo o el código apuntan a un único componente, el comportamiento esperado es inequívoco y se puede escribir antes una prueba que falle, además abre un pull request con la corrección y esa prueba, lo vincula a la issue y pide revisión. Las utilidades compartidas, los tokens de diseño y todo lo que requiere una decisión de producto se reportan en lugar de cambiarse. Zero nunca fusiona: cada corrección llega como un pull request que tú revisas.
¿Puede Zero asignar la issue a la persona correcta automáticamente?
Sí. Zero empareja el nombre que menciones, o el nombre visible en Slack de quien reporta, con los usuarios de GitHub del repositorio y asigna la issue. Nombrar al responsable en el mensaje es lo más fiable; cuando no se nombra a nadie, Zero recurre a quien es propietario del área que apunta el hilo y deja escrito en la issue cómo lo decidió.
¿Cómo evita Zero crear issues de GitHub duplicadas?
Antes de crear nada, Zero busca en las issues abiertas el mismo síntoma, área afectada y formulación. Cuando encuentra una coincidencia añade el nuevo hilo de Slack como comentario en esa issue, con quien reporta y la marca de tiempo, y responde en Slack con el enlace de la issue existente en lugar de abrir una segunda.
¿Qué pasa si un reporte de error no trae pasos para reproducir?
Zero crea la issue igualmente para que el reporte no se pierda, la etiqueta como pendiente de pasos para reproducir y responde en el hilo de Slack pidiéndolos. La respuesta acaba así en el hilo que ya está enlazado desde la issue.
¿Puede Zero crear issues de un canal entero de forma programada?
Sí. Apunta Zero a uno o varios canales y dale una periodicidad, por ejemplo cada viernes a las 16:00. Lee los mensajes de la semana, crea una issue por cada uno que describa un defecto, comenta los duplicados, omite peticiones de funcionalidad y preguntas, e informa de lo que hizo.
¿Funciona con Linear o Jira en lugar de GitHub?
La misma forma de flujo sirve para cualquier gestor al que Zero esté conectado; esta página cubre la vía de GitHub, que usa el conector de GitHub. Linear se conecta igual, y el gestor lo indicas en la instrucción.
Reporta tu próximo error sin salir de Slack
Conecta Slack y GitHub, describe el error como se lo contarías a un compañero y deja que Zero escriba la issue y la asigne. Cuando la causa está acotada, el pull request también te está esperando.