--- name: weekly-3p-update description: 從 Slack 討論串、任務清單、文件或筆記，寫出團隊或專案的每週 3P 更新（Progress 進度、Plans 計畫、Problems 問題），讓讀者 60 秒內看完。適用於有人要每週更新、進度報告、週報、3P、給主管的團隊更新，或問「這週做了什麼」的時候。 license: Apache-2.0 (see LICENSE.txt). Adapted from anthropics/skills internal-comms. --- # 每週 3P 更新（進度、計畫、問題） 3P 更新讓主管和相鄰的團隊在一分鐘內知道：什麼有進展、接下來做什麼、什麼卡住了。讀者對團隊有一些了解，但不多。寫得短、寫事實，團隊有數字就放數字。 ## 適用情境 - 每週給主管、高層或公司頻道的團隊或專案更新。 - 給只想看重點的客戶或合作夥伴的進度更新。 - 不適用於上線公告或長篇的專案回顧：那些內容每段遠不只三行。 ## 需要準備 - 團隊或專案名稱，以及涵蓋的期間（進度和問題通常是過去 7 天，計畫是接下來 7 天）。缺任何一項，問一次。 - 原始材料：Slack 貼文、已完成的任務、文件、會議紀錄、指標。能讀取團隊的工具就直接從中整理；不能的話，請使用者貼上要涵蓋的內容。 - 選填：上週的更新，用來對照上週的計畫和本週的進度。 ## 步驟 1. **確定範圍。** 確認團隊名稱和日期。團隊越大，項目越粗：小組寫「上線了匯出按鈕」，全公司寫「簽下 4 筆新的企業合約」。 2. **從工作發生的地方蒐集。** 優先看回覆或表情回應多的貼文、很多人打開的文件、已完成的任務，以及重要的非例行會議（審查、客戶通話）。忽略日常閒聊。 3. **挑出重要的。** 進度：上線的東西、達成的里程碑、有變化的數字。計畫：下週最優先的 1 到 3 件事。問題：拖慢團隊的事，例如卡關、缺人、沒談成的案子、對其他團隊的依賴。 4. **對照上週的計畫。** 上週的每一項計畫，要嘛在進度裡寫成已完成，要嘛在問題裡寫出延誤的原因。不要讓任何計畫悄悄消失。 5. **每段寫 1 到 3 句。** 就事論事，不用形容詞代替數字。寫出指標和變化（「試用註冊 120 → 145」），而不是「大幅成長」。 6. **有需要就加一個請求。** 如果某個問題需要讀者做決定或幫忙，在問題那一行寫清楚找誰、要什麼。 ## 輸出格式 照這個格式寫，不要改動。一行標題，接著三個有標籤的段落。 ```markdown [符合本週的 emoji] [團隊名稱]（[涵蓋日期]） **進度：** [1–3 句：上線、達成、量測到的結果] **計畫：** [1–3 句：下週最優先的事] **問題：** [1–3 句：卡關的事和請求，或「本週沒有。」] ``` ## 範例 **輸入（筆記）：** 金流組，3月10日至14日。週三上線年繳方案，目前有 18 位客戶改為年繳。退款流程改版在審查中。下週：寄年繳方案的通知信給所有月繳客戶，開始做發票 PDF。新的退款說明文字從週一起就在等法務回覆；需要法務在週三前答覆，改版才能在下週上線。上週的計畫「修正營業稅四捨五入」已在週二完成。 **輸出：** ```markdown 💳 金流組（3月10日至14日） **進度：** 年繳方案週三上線，已有 18 位客戶改為年繳。營業稅四捨五入的修正週二上線。退款流程改版正在審查。 **計畫：** 寄年繳方案的通知信給所有月繳客戶，並開始做發票 PDF。 **問題：** 新的退款說明文字從 3月10日起一直在等法務回覆；需要法務在週三前答覆，改版才能在下週上線。 ``` ## 寄出前檢查 - [ ] 標題寫了團隊名稱和日期。 - [ ] 每段不超過 3 句，整份更新 60 秒內讀得完。 - [ ] 每一項進度都有數字、日期或具體的交付成果。 - [ ] 上週的每一項計畫都出現在進度或問題裡。 - [ ] 每個需要協助的問題都寫了該由誰處理、何時之前。 - [ ] 沒有出現你讀過的資料裡沒有的事實。 ## 常見錯誤 - 列活動（「開了 6 次定價會議」）而不是列成果（「新價格已定案，4月1日上線」）。 - 把延誤的計畫藏起來。讀者記得上週的更新。 - 把問題寫成抱怨卻沒有請求。寫出什麼能讓事情繼續往前走。 --- 改編自 github.com/anthropics/skills 中的 `internal-comms` 技能（examples/3p-updates.md），Copyright 2026 Anthropic, PBC，依 Apache License, Version 2.0 授權（LICENSE.txt）。Fluxenic Inc. 的修改：為非工程團隊改寫，加入步驟、上週計畫的對照檢查、範例和檢查清單。