將 Slack 發佈更新轉化為面向客戶的發佈說明草稿

概覽

Computer 自動化會每小時檢查 Slack 以尋找已確認面向客戶發佈的內容，檢視連結的 GitHub 變更、Linear 問題以及 Notion 中的產品專案，然後檢查先前的發佈說明以防重複並確認已核准的命名。它會準備面向客戶的發佈說明草稿和團隊摘要以供審查，而不會進行發佈或張貼。

首次結果所需時間：在下一次每小時檢查找到符合資格的出貨訊息後；請求立即執行以取得第一個範例。

難度：需要設定

您需要什麼

• Slack 已連線並具有 [release channel] 的存取權，以便識別已確認面向客戶發佈的內容。
• GitHub 與 Linear 已連線並具有連結的 pull request 與問題的存取權，以便草稿反映已出貨的功能範圍。
• Notion 已連線至 [product Project]，以便已核准面向客戶的名稱來引導草稿。
• 包含先前項目與命名規則的發佈說明總帳，以便檢查重複項目與過時名稱。
• 每小時檢查排程與審查負責人，以便符合資格的更新會變成待核准的草稿，而不是已發佈的說明。

查詢

您會得到什麼

排程報告傳遞：審查草稿

包含虛構產品詳細資料和說明性來源連結的示範輸出。完成草稿的摘要：

命名檢查：

「產品專案確認 "Scheduled Report Delivery" 是已核准的名稱。草稿會逐字使用它。類別為「新功能」。」

重複檢查：

「LIN-4955、PR-3389 或 "Scheduled Report Delivery" 沒有先前的項目。」

團隊摘要：

「建議的發佈標籤 v2026.09.19-1。」

在來源工作中檢視完整的示範草稿與總帳。

• 來源審查：示範列出了 GitHub pull request、Linear 問題與母屬 epic，以及 Notion 產品專案。
• 命名檢查：「Scheduled Report Delivery」取代了較舊的「Report Scheduler」標籤。
• 重複檢查：將功能名稱、問題 ID 和 pull request 與先前的發佈說明進行比較。
• 發佈說明草稿：供審查的建議標題、類別、發佈標籤、效益聲明和功能要點。
• 團隊摘要：說明變更、命名決定和重複檢查的草稿 Slack 討論串回覆。
• 發佈說明總帳：供後續審查的三個說明性先前項目與命名慣例。

以 Markdown 草稿和獨立的 Markdown 總帳形式交付，隨時可供審查與修訂；示範未顯示已發佈的發佈說明或已張貼的 Slack 回覆。

使其更好

• 新增內容：包含已核准的發佈說明與已確認的方案可用性，以引導用詞和資格宣告。
• 指定具體項目：命名定義發佈的 Slack 頻道、GitHub 儲存庫、Linear 團隊和 Notion 專案。
• 要求格式：在每份草稿中要求客戶效益、可用性宣告、功能要點和來源參考。
• 使用技能：將已核准的發佈說明結構和命名規則儲存為可重複使用的技能。
• 使其成為定期執行：指定檢查時間和時區，並要求在沒有符合資格的變更出現時保持靜默。

嘗試變化

檢視 [Slack ship-message link]、其連結的 GitHub 變更、相關的 Linear issues 以及 [product Project in Notion]。檢查 [release notes ledger] 是否有重複項以及已核准的命名。草擬一個 Markdown 發佈說明項目與團隊摘要供審查。請勿排程、發佈或張貼任何內容。

每小時檢查 [Slack channel] 是否有 [GitHub repository] 中已出貨、面向客戶的錯誤修正。檢視相關的 Linear 問題、[product Project in Notion] 以及 [release notes ledger]。在「已修正」類別中草擬 Markdown 項目以及供審查的團隊摘要。請勿發佈或張貼任何內容。

每逢 [Friday at time and time zone]，根據連結的 GitHub 變更、Linear 問題、[product Project in Notion] 和 [release notes ledger]，檢視 [Slack channel] 中已確認發佈的內容。建立包含客戶效益、已核准名稱和重複檢查結果的單頁 Markdown 發佈摘要。保留此內容以供審查。

相關使用案例

• Computer 在 Slack 中傳送每日產品開發摘要：確保產品團隊在做出決策和實作變更之前對齊意見，然後才將其作為發佈公告。
• 自動化說明中心文章：將產品文件轉化為說明文章，解釋如何使用新發佈的功能。
• 為您的公司偵測過時的到達網頁：將公開網頁與最新發佈說明進行比較，以便在推出後標記過時的宣告。