Transformez les mises à jour de version Slack en projets de notes de version destinés aux clients

Aperçu

Un Computer vérifie toutes les heures sur Slack s'il y a des versions confirmées destinées aux clients, examine les modifications GitHub associées, les problèmes Linear et le projet produit dans Notion, puis vérifie les notes de version précédentes pour détecter les doublons et les dénominations approuvées. Il prépare un projet de notes de version destiné aux clients et un résumé pour l'équipe aux fins d'examen, sans publication ni diffusion.

Délai avant le premier résultat : Après que la prochaine vérification horaire a trouvé un message d'envoi admissible, demandez une exécution immédiate pour un premier exemple.

Difficulté : nécessite une configuration

Ce dont vous avez besoin

• Slack connecté avec accès au [canal de version], afin que les versions confirmées destinées aux clients puissent être identifiées.
• GitHub et Linear connectés avec accès aux pull requests et aux problèmes liés, afin que les projets reflètent la portée livrée.
• Notion connecté au [projet de produit], afin que les noms approuvés destinés aux clients guident le projet.
• Un registre de notes de version comportant 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 de l'examen, afin que les mises à jour admissibles deviennent des projets soumis à approbation plutôt que des notes publiées.

La requête

Ce que vous obtenez en retour

Livraison de rapports planifiés : projet pour examen

Sortie de démonstration avec des détails de produits fictifs et des liens de source illustratifs. Extraits du projet achevé :

Vérification de la dénomination :

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

Vérification des doublons :

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

Résumé pour l'équipe :

« Balise de version proposée v2026.09.19-1. »

Affichez le projet de démonstration complet et le registre dans la tâche source.

• Examen de la source : La démonstration répertorie une pull request GitHub, un problème Linear et une épique parente, ainsi qu'un projet de produit Notion.
• Vérification de la dénomination : « Scheduled Report Delivery » remplace l'ancienne étiquette « Report Scheduler ».
• Vérification des doublons : Le nom de la fonctionnalité, l'ID du problème et la pull request sont comparés aux notes de version précédentes.
• Projet de notes de version : Un titre proposé, une catégorie, une balise de version, un énoncé des avantages et des puces de fonctionnalités aux fins d'examen.
• Résumé pour l'équipe : Un projet 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.

Fourni sous forme de projet Markdown et d'un registre Markdown distinct, prêts pour l'examen et la révision ; la démonstration ne montre pas de note de version publiée ni de réponse Slack diffusé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 déclarations d'admissibilité.
• Indiquer des éléments précis : 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 avantage client, un énoncé de disponibilité, des puces de fonctionnalités et des références de source dans chaque projet.
• Utiliser une compétence : Enregistrez la structure de 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 admissible n'apparaît.

Essayer une variante

Examinez le [lien du message d'envoi Slack], ses modifications GitHub associées, les problèmes Linear connexes et le [projet de 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 examen. Ne planifiez, ne publiez et ne diffusez rien.

Chaque heure, vérifiez le [canal Slack] pour les corrections de bogues expédiées destinées aux clients dans le [dépôt GitHub]. Examinez les problèmes Linear connexes, le [projet de 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 aux fins d'examen. Ne publiez ou ne diffusez rien.

Tous les [vendredis à l'heure et dans le fuseau horaire], examinez les versions confirmées dans le [canal Slack] par rapport aux modifications GitHub associées, aux problèmes Linear, au [projet de produit dans Notion] et au [registre des notes de version]. Créez un condensé 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 examen.

Cas d'utilisation associés

• Le Computer envoie un récapitulatif quotidien du développement de produits sur Slack : Maintenez l'équipe produit 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 aux dernières notes de version pour signaler les déclarations obsolètes après un lancement.