Trasforma gli aggiornamenti dei rilasci da Slack in bozze di note di rilascio per i clienti

Panoramica

Un Computer automazione controlla Slack ogni ora per verificare la presenza di rilasci confermati destinati ai clienti, esamina le modifiche collegate su GitHub, i problemi su Linear e il progetto di prodotto in Notion, quindi verifica nelle note di rilascio precedenti la presenza di duplicati e denominazioni approvate. Prepara una bozza delle note di rilascio destinate ai clienti e un riepilogo per il team da revisionare, senza pubblicare o inviare nulla.

Tempo al primo risultato: dopo che il successivo controllo orario rileva un messaggio di rilascio idoneo; richiede un'esecuzione immediata per un primo esempio.

Difficoltà: richiede configurazione

Cosa serve

• Slack connesso con accesso al [canale dei rilasci], in modo da poter identificare i rilasci confermati destinati ai clienti.
• GitHub e Linear connessi con accesso alle pull request e ai problemi collegati, affinché le bozze riflettano l'ambito rilasciato.
• Notion connesso al [progetto di prodotto], in modo che i nomi approvati destinati ai clienti guidino la bozza.
• Un registro delle note di rilascio con voci precedenti e regole di denominazione, per poter verificare duplicati e nomi obsoleti.
• Una pianificazione dei controlli orari e un responsabile della revisione, affinché gli aggiornamenti idonei diventino bozze da approvare anziché note pubblicate.

La query

Cosa si ottiene

Consegna del report pianificato: bozza per la revisione

Output di demo con dettagli di prodotto fittizi e link di origine dimostrativi. Estratti dalla bozza completata:

Controllo della denominazione:

“Il progetto di prodotto conferma che "Scheduled Report Delivery" è il nome approvato. La bozza lo utilizza testualmente. La categoria è Nuovo.”

Controllo dei duplicati:

“Nessuna voce precedente per LIN-4955, PR-3389 o "Scheduled Report Delivery".”

Riepilogo per il team:

“Tag di rilascio proposto v2026.09.19-1.”

Visualizza la bozza di demo completa e il registro nell'attività di origine.

• Revisione dell'origine: la demo elenca una pull request di GitHub, un problema di Linear con la relativa epica principale e un progetto di prodotto in Notion.
• Controllo della denominazione: "Scheduled Report Delivery" sostituisce la precedente etichetta "Report Scheduler".
• Controllo dei duplicati: il nome della funzionalità, l'ID del problema e la pull request vengono confrontati con le note di rilascio precedenti.
• Bozza delle note di rilascio: un titolo proposto, una categoria, un tag di rilascio, una dichiarazione dei benefici e punti elenco delle funzionalità per la revisione.
• Riepilogo per il team: una bozza di risposta in un thread di Slack che spiega la modifica, la decisione sulla denominazione e il controllo dei duplicati.
• Registro delle note di rilascio: tre voci precedenti dimostrative e convenzioni di denominazione per le revisioni successive.

Fornito come bozza in Markdown e registro separato in Markdown, pronti per la revisione e la modifica; la demo non mostra una nota di rilascio pubblicata o una risposta inviata su Slack.

Miglioralo

• Aggiungi contesto: includi note di rilascio approvate e disponibilità confermata del piano per guidare la formulazione e le affermazioni di idoneità.
• Indica elementi specifici: nomina il canale Slack, i repository GitHub, il team Linear e il progetto Notion che definiscono il rilascio.
• Richiedi il formato: richiedi un beneficio per il cliente, una dichiarazione di disponibilità, punti elenco delle funzionalità e riferimenti di origine in ogni bozza.
• Usa una Skill: salva la struttura delle note di rilascio approvata e le regole di denominazione come Skill riutilizzabile.
• Rendilo ricorrente: specifica gli orari dei controlli e un fuso orario e richiedi il silenzio quando non compaiono modifiche idonee.

Prova una variante

Esamina [link del messaggio di spedizione su Slack], le relative modifiche su GitHub, i problemi correlati su Linear e il [progetto di prodotto in Notion]. Controlla il [registro delle note di rilascio] per verificare duplicati e denominazioni approvate. Redigi una voce di nota di rilascio in Markdown e un riepilogo per il team per la revisione. Non programmare, pubblicare o inviare nulla.

Ogni ora, controlla il [canale Slack] per verificare la presenza di correzioni di bug destinate ai clienti rilasciate nel [repository GitHub]. Esamina i problemi correlati su Linear, il [progetto di prodotto in Notion] e il [registro delle note di rilascio]. Redigi voci in Markdown nella categoria Corretto con un riepilogo per il team per la revisione. Non pubblicare o inviare nulla.

Ogni [venerdì all'ora e nel fuso orario specificati], esamina i rilasci confermati nel [canale Slack] rispetto alle modifiche collegate su GitHub, ai problemi su Linear, al [progetto di prodotto in Notion] e al [registro delle note di rilascio]. Crea un riepilogo dei rilasci in Markdown di una pagina con i benefici per i clienti, i nomi approvati e i risultati del controllo dei duplicati. Conservalo per la revisione.

Casi d'uso correlati

• Il Computer invia un riepilogo giornaliero dello sviluppo del prodotto in Slack: mantieni il team di prodotto allineato sulle decisioni e sulle modifiche di implementazione prima che diventino annunci di rilascio.
• Automatizza gli articoli del centro assistenza: trasforma la documentazione di prodotto in articoli di aiuto che spiegano come utilizzare le funzionalità appena rilasciate.
• Rileva landing page obsolete per la tua azienda: confronta le pagine pubbliche con le ultime note di rilascio per segnalare affermazioni obsolete dopo un lancio.