Converte actualizacións de lanzamento de Slack en borradores de notas de versión para clientes

Resumo

Unha automatización de Computer comproba en Slack cada hora se hai lanzamentos confirmados orientados ao cliente, revisa os cambios de GitHub vinculados, as incidencias de Linear e o proxecto de produto en Notion, e logo comproba nas notas de versión anteriores se hai duplicados e nomes aprobados. Prepara un borrador de notas de versión orientadas ao cliente e un resumo de equipos para a súa revisión sen publicar nin enviar nada.

Tempo ata o primeiro resultado: Despois de que a seguinte comprobación horaria atope unha mensaxe de envío que cumpra cos requisitos; solicita unha execución inmediata para ver un primeiro exemplo.

Dificultade: necesita configuración

O que necesitas

• Slack conectado con acceso a [canal de lanzamento], para poder identificar os lanzamentos confirmados orientados ao cliente.
• GitHub e Linear conectados con acceso ás pull request e incidencias vinculadas, para que os borradores reflictan o ámbito enviado.
• Notion conectado a [proxecto de produto], para que os nomes aprobados orientados ao cliente guíen o borrador.
• Un rexistro de notas de versión con entradas anteriores e regras de nomenclatura, para poder comprobar os duplicados e os nomes obsoleto.
• Un horario de comprobacións por hora e un responsable de revisión, para que as actualizacións que cumpran cos requisitos se converten en borradores para a súa aprobación en lugar de notas publicadas.

A consulta

O que recibes de volta

Entrega de informes programada: borrador para revisión

Saída de demostración con detalles de produto ficticios e ligazóns de orixe ilustrativas. Extractos do borrador completado:

Comprobación de nomes:

"O proxecto de produto confirma que \"Scheduled Report Delivery\" é o nome aprobado. O borrador utilízao literalmente. A categoría é Novo."

Comprobación de duplicados:

"Non hai ningunha entrada previa para LIN-4955, PR-3389 ou \"Scheduled Report Delivery\"."

Resumo de equipos:

"Etiqueta de lanzamento proposta v2026.09.19-1."

Ver o borrador de demostración completo e o rexistro na tarefa de orixe.

• Revisión de orixe: A demostración enumera unha pull request de GitHub, unha incidencia de Linear e un epic principal, e un proxecto de produto de Notion.
• Comprobación de nomes: \"Scheduled Report Delivery\" substitúe a etiqueta anterior \"Report Scheduler\":
• Comprobación de duplicados: O nome da funcionalidade, o ID da incidencia e a pull request compáranse coas notas de versión anteriores.
• Borrador de notas de versión: Un título proposto, categoría, etiqueta de lanzamento, declaración de beneficios e viñetas de funcionalidades para revisión.
• Resumo de equipos: Un borrador de resposta nun fío de Slack que explica o cambio, a decisión de nomenclatura e a comprobación de duplicados.
• Rexistro de notas de versión: Tres entradas anteriores ilustrativas e convencións de nomenclatura para revisións posteriores.

Entregado como un borrador en Markdown e un rexistro en Markdown separado, listo para revisión e revisión; a demostración non mostra unha nota de versión publicada nin unha resposta de Slack publicada.

Mellora isto

• Engadir contexto: Inclúe notas de versión aprobadas e dispoñibilidade de plans confirmada para guiar a redacción e as reclamacións de elixibilidade.
• Apunta a detalles específicos: Nomea o canal de Slack, os repositorios de GitHub, o equipo de Linear e o proxecto de Notion que definen o lanzamento.
• Solicitar o formato: Solicita un beneficio para o cliente, declaración de dispoñibilidade, viñetas de funcionalidades e referencias de orixe en cada borrador.
• Usa un Skill: Garda a estrutura de notas de versión aprobada e as regras de nomenclatura como un Skill reutilizable.
• Faino recorrente: Especifica as horas de comprobación e unha zona horaria, e pide silencio cando non apareza ningún cambio que cumpra os requisitos.

Proba unha variación

Revisa [ligazón á mensaxe de envío de Slack], os seus cambios de GitHub vinculados, as incidencias de Linear relacionadas e o [proxecto de produto en Notion]. Comproba no [rexistro de notas de versión] se hai duplicados e nomes aprobados. Redacta unha entrada de notas de versión en Markdown e un resumo de equipos para revisión. Non programes, publiques nin envíes nada.

Cada hora, comproba no [canal de Slack] se hai correccións de erros orientadas ao cliente enviadas no [repositorio de GitHub]. Revisa as incidencias de Linear relacionadas, o [proxecto de produto en Notion] e o [rexistro de notas de versión]. Redacta entradas en Markdown na categoría Corrixido cun resumo de equipos para revisión. Non publiques nin envíes nada.

Cada [venres á hora e zona horaria], revisa os lanzamentos confirmados en [canal de Slack] fronte aos cambios de GitHub vinculados, as incidencias de Linear, o [proxecto de produto en Notion] e o [rexistro de notas de versión]. Crea un resumo de versións en Markdown dunha páxina con beneficios para o cliente, nomes aprobados e resultados da comprobación de duplicados. Mânteo para revisión.

Casos de uso relacionados

• Computer envía un resumo diario de desenvolvemento de produtos en Slack: Mantén ao equipo de produto alineado nas decisións e nos cambios de implementación antes de que se convertan en anuncios de lanzamento.
• Automatizar os artigos do centro de axuda: Converte a documentación do produto en artigos de axuda que expliquen como usar as funcionalidades recén lanzadas.
• Detectar páxinas de destino obsoletas para a túa empresa: Compara as páxinas públicas coas últimas notas de versión para sinalar afirmacións obsoletas despois dun lanzamento.