Transformez les mises à jour de version Slack en brouillons de notes de version pour les clients

Aperçu

Une automatisation Computer vérifie Slack toutes les heures pour identifier les versions confirmées destinées aux clients, examine les modifications GitHub liées, les tickets Linear et le projet produit dans Notion, puis consulte les notes de version précédentes pour détecter les doublons et les dénominations approuvées. Elle prépare un projet de notes de version destiné aux clients et un résumé pour l'équipe pour révision, sans rien publier ni poster.

Délai avant le premier résultat : Une fois que la prochaine vérification horaire trouve un message de livraison éligible, demandez une exécution immédiate pour un premier exemple.

Difficulté : nécessite une configuration

Ce dont vous avez besoin

• Slack connecté avec un accès au [canal de version] pour identifier les versions confirmées destinées aux clients.
• GitHub et Linear connectés avec un accès aux pull requests et aux tickets liés, afin que les brouillons reflètent le périmètre déployé.
• Notion connecté au [projet produit] pour guider le brouillon avec les noms approuvés destinés aux clients.
• Un registre de notes de version contenant les entrées précédentes et les règles de dénomination, afin de pouvoir vérifier les doublons et les noms obsolètes.
• Un calendrier de vérification horaire et un responsable des révisions, afin que les mises à jour éligibles deviennent des brouillons à approuver plutôt que des notes publiées.

La requête

Ce que vous obtenez

Rapport programmé : brouillon à réviser

Sortie de démonstration avec des détails de produit fictifs et des liens sources illustratifs. Extraits du brouillon finalisé :

Vérification des noms :

« Le projet produit confirme que "Scheduled Report Delivery" est le nom approuvé. Le brouillon l'utilise tel quel. La catégorie est Nouveau. »

Vérification des doublons :

« Aucune entrée précédente pour LIN-4955, PR-3389 ou "Scheduled Report Delivery". »

Résumé pour l'équipe :

« Proposition de tag de version v2026.09.19-1. »

Consultez le brouillon de démonstration complet et le registre dans la tâche source.

• Examen de la source : La démo répertorie une pull request GitHub, un ticket Linear et son épopée parente, ainsi qu'un projet produit Notion.
• Vérification des noms : « Scheduled Report Delivery » remplace l'ancienne étiquette « Report Scheduler ».
• Vérification des doublons : Le nom de la fonctionnalité, l'ID du ticket et la pull request sont comparés aux notes de version précédentes.
• Brouillon de notes de version : Un titre proposé, une catégorie, un tag de version, une déclaration de bénéfice et des points clés de fonctionnalité à réviser.
• Résumé pour l'équipe : Un brouillon de réponse dans le fil Slack expliquant la modification, la décision de dénomination et la vérification des doublons.
• Registre des notes de version : Trois entrées antérieures illustratives et conventions de dénomination pour les examens ultérieurs.

Livré sous forme de brouillon Markdown et d'un registre Markdown séparé, prêts pour révision et modification ; la démo n'affiche pas de note de version publiée ni de réponse Slack postée.

Améliorer

• Ajouter du contexte : Incluez des notes de version approuvées et la disponibilité confirmée du plan pour guider la formulation et les critères d'éligibilité.
• Préciser les éléments : Nommez le canal Slack, les dépôts GitHub, l'équipe Linear et le projet Notion qui définissent la version.
• Demander le format : Demandez un bénéfice client, une déclaration de disponibilité, des points clés de fonctionnalité et des références sources dans chaque brouillon.
• Utiliser un Skill : Enregistrez la structure des notes de version approuvée et les règles de dénomination en tant que Skill réutilisable.
• Rendre récurrent : Spécifiez les heures de vérification et un fuseau horaire, et demandez le silence lorsqu'aucune modification éligible n'apparaît.

Essayer une variante

Examinez le [lien du message de livraison Slack], ses modifications GitHub liées, les tickets Linear associés et le [projet produit dans Notion]. Vérifiez le [registre des notes de version] pour détecter les doublons et les dénominations approuvées. Rédigez une entrée de notes de version en Markdown et un résumé pour l'équipe pour révision. Ne planifiez, ne publiez et ne postez rien.

Toutes les heures, vérifiez le [canal Slack] pour identifier les corrections de bugs destinées aux clients déployées dans le [dépôt GitHub]. Examinez les tickets Linear associés, le [projet produit dans Notion] et le [registre des notes de version]. Rédigez des entrées en Markdown dans la catégorie Correctifs avec un résumé pour l'équipe pour révision. Ne publiez et ne postez rien.

Chaque [vendredi à l'heure et dans le fuseau horaire indiqués], examinez les versions confirmées dans le [canal Slack] par rapport aux modifications GitHub liées, aux tickets Linear, au [projet produit dans Notion] et au [registre des notes de version]. Créez un récapitulatif de version d'une page en Markdown avec les avantages pour les clients, les noms approuvés et les résultats de la vérification des doublons. Conservez-le pour révision.

Cas d'usage associés

• Computer envoie un briefing quotidien sur le développement de produits dans Slack : Assurez-vous que l'équipe produit est alignée sur les décisions et les modifications d'implémentation avant qu'elles ne deviennent des annonces de version.
• Automatiser les articles du centre d'aide : Transformez la documentation produit en articles d'aide qui expliquent comment utiliser les fonctionnalités nouvellement publiées.
• Détecter les pages de destination obsolètes pour votre entreprise : Comparez les pages publiques avec les dernières notes de version pour signaler les déclarations obsolètes après un lancement.