設定
試用外掛程式
Product Management 外掛程式內建 /stakeholder-update 和其他發布技能作為起點，已經結構化以建立檢查清單、指派狀態，並做出是否發布的判斷。如果您的管理員負責管理外掛程式，而且目前尚未提供此功能，可以跳過此步驟；以下內容都不需要它。
/stakeholder-updateSweep launch readiness across PRD, epic, Slack, and GTM brief and make the go/no-go call/metrics-reviewExplain a metric move with segment isolation and ship correlation連接您的工具
當 Claude Cowork 直接與您的系統協作時，功能會更強大。您可以控制權限和存取權。了解工具存取權（在新分頁中開啟）。
在 Cowork 中前往自訂 → 連接器進行設定。
設定您的工作資料夾
將您要使用的檔案（PRD、GTM 簡報、發布檢查清單範本、上兩次發布的回顧報告）拖曳到您機器上的一個資料夾中，然後讓 Cowork 指向該資料夾。Cowork 會從中讀取並將準備度檢查清單寫回該資料夾。如果您經常進行發布，請從該資料夾建立 Cowork 專案（在新分頁中開啟），讓您的檢查清單範本、先前的回顧報告和記憶保持連結。
提示內容
將此內容複製到 Claude Cowork
針對已儲存視圖的發布進行準備度檢查。產出每項都有狀態和負責人的發布檢查清單，給出整體紅/黃/綠燈準備度判斷，列出阻礙因素，並註明任何與我們過去兩次發布中順利或出問題的地方相符的內容。
為什麼這樣做有效
一次提供所有來源。 PRD、epic、Slack 和 GTM 簡報各自掌握真相的不同片段；一次性檢查這些內容，才能抓到在 Linear 中標示「完成」但在頻道中仍在爭論的項目。
要求每一項都有負責人。 每一行都有名字的檢查清單，在發布站立會議中才具有可執行性；沒有負責人的檢查清單只是一份願望清單。
要求附帶理由的判斷。 要求整體的紅/黃/綠燈判斷會強制做出判斷，而「列出具體的阻礙因素」意味著黃燈會附帶兩件必須解決的事項，而不只是一種感覺。
與您自己的歷史記錄比較。 讓 Claude 參考您過去的回顧報告，可以讓它根據以前出過問題的地方來檢查這次發布。否則它只是孤立地進行評估。
取得更好的草稿
加入一個範例來對照。 將您喜歡的範例放入資料夾，Cowork 就會配合您的結構和語氣。
要求它標示不確定之處。 加上「標示出您不確定的任何內容」，這樣您在審閱草稿時就知道該先看哪裡。
讓 Cowork 為您所用
外掛程式技能只是一個起點——用您自己的實務做法和專業知識來客製化它。只需幾分鐘的對話，之後它就會依照您的標準運作。
把我們在這項任務中目前所做的內容變成一項技能，或根據我的意見編輯 /stakeholder-update 技能。
讓它可重複執行
在發布週期間每天執行
在最後衝刺階段，準備度每小時都在變化。在提示中輸入 /schedule，或在 Cowork 側邊欄開啟已排程，客製化的技能就會在發布週的每天早上發布最新的檢查清單，讓站立會議一開始就能看到最新狀況。
/schedule 從 5 月 4 日到 5 月 8 日，每個工作日上午 8 點，針對已儲存視圖的發布執行 /stakeholder-update，並將檢查清單寫入 Launches/saved-views，檔名為 readiness-<date>.md，並附上與昨天相比的一行顏色變化說明。
針對 PRD、Linear epic、Slack 頻道和 GTM 簡報執行 /stakeholder-update，並將附有整體顏色的日期檢查清單寫入發布資料夾。
與您的團隊成員分享
您客製化的 /stakeholder-update 現在帶有您的檢查清單範本、您的負責人，以及您的顏色判斷標準。分享它，讓每位發布負責人都執行相同的檢查，而無論哪個功能要發布，是否發布的會議都能讀到一致的格式。