← LeaderboardThe Skill Leaderboard

meeting-notes

按產品經理的最佳實踐整理會議紀要。當被要求寫會議紀要、整理討論記錄、記錄待辦事項或記錄任何型別會議的決定時使用。產出結構化紀要：決定、待辦事項（負責人加截止日期）、待解決問題和下一步。

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

meeting-notes

Start a fresh conversation. Replace the highlighted placeholders.

Use meeting-notes to organize a structured meeting summary for [meeting name and date, attendees with roles, raw notes or transcript, and meeting type], including a list of decisions with background, action items with single owners and deadlines, unresolved issues, and next steps.

Required inputs

[meeting name and date, attendees with roles, raw notes or transcript, and meeting type]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: meeting-noteslanguage: zh-TWdescription: "按產品經理的最佳實踐整理會議紀要。當被要求寫會議紀要、整理討論記錄、記錄待辦事項或記錄任何型別會議的決定時使用。產出結構化紀要：決定、待辦事項（負責人加截止日期）、待解決問題和下一步。"

meeting-notes 的繁體中文翻譯，英文版本為規範版本。

會議紀要

這個技能整理會議紀要，讓它發揮最大價值，並確保事情落地。

所需輸入

如未提供，請向使用者詢問：

會議名稱和日期
參會人（姓名和角色）
原始筆記或文字記錄（貼上討論筆記、文字記錄，或描述討論了什麼）
會議型別（一對一 / 迭代規劃 / 產品評審 / 干係人同步 / 其他），決定使用哪個模板

從大腦讀取 / 寫入大腦

如果存在 professional-brain（brain/），紀要就在這裡變成長期記憶：

先讀： 相關的 stakeholders/ 檔案（這樣你進會議時就知道每位參會人未解決的請求和顧慮），以及會議要重新討論的 decisions/。
之後寫： 把每個決定（附理由和 reopen-when）追加到 decisions/，把新的請求或顧慮加入對應的 stakeholders/ 檔案，把任何新的假設記入 hypotheses/。給每條記錄的事實標註來源：大多數會議發言在被獨立確認之前都是 [verbal]。把原始筆記儲存到 source/。

標準會議紀要模板

會議抬頭

會議：[會議名稱] 日期：[日期] 參會人：[姓名 / 角色] 記錄人：[姓名] 時長：[實際時長]

議程

議題 1
議題 2
議題 3

（討論過的勾選）

已做出的決定

清楚記錄決定：

決定：[決定了什麼] 背景：[為什麼這樣決定] 負責人：[誰負責執行] 截止日期：[如適用]

每個決定都用這個格式。

待辦事項

所有待辦事項應寫成：

[待辦事項] - @負責人 - 截止：[日期]
[待辦事項] - @負責人 - 截止：[日期]

格式要求：

清楚、具體的行動
單一負責人（不能是"團隊"）
明確的截止日期
用勾選框跟蹤

討論要點

按議題整理討論的關鍵點：

議題 1：[名稱]

關鍵觀點或討論重點
提出的重要背景或顧慮
分享的資料或資訊

議題 2：[名稱]

關鍵討論點
達成的決定或結論

待解決問題 / 跟進

沒能回答的問題：

問題：[我們需要知道什麼]
負責人：[誰去查清楚]
截止：[日期]

下一步

清楚總結接下來會發生什麼：

[緊接著的行動]
[如需要，跟進會議]
[需要啟動的更大流程]

最佳實踐

會議中：

關注決定和待辦，而不是對話本身
記錄具體的承諾，而不是泛泛的討論
重要決定上記錄反對意見
對含糊的承諾要求說清楚（"我去看看" → "我會分析資料，週五前分享結論"）

會議後：

趁記憶新鮮，2 小時內發出紀要
@ 待辦事項的負責人
附上相關文件連結
跟進逾期的待辦

要記錄什麼： ✅ 已做出的決定 ✅ 有負責人和截止日期的待辦 ✅ 討論的關鍵點 ✅ 待解決問題 ✅ 下一步

不要記錄什麼： ❌ 逐字記錄 ❌ 跑題的內容 ❌ 做決定之前的初步討論 ❌ 重複的資訊

會議型別與調整

一對一會議

關注：

職業發展討論
反饋（雙向）
當前的挑戰
雙方的待辦

模板補充：

近期成績：進展順利的事
挑戰：不順利的事
職業討論：發展話題
反饋：給雙方

迭代規劃

關注：

故事的驗收標準
估算決定
識別依賴
迭代承諾

模板補充：

迭代目標：我們承諾什麼
故事點：容量和估算
依賴：外部阻礙
完成定義：驗收標準

產品評審

關注：

設計決定
討論的使用者反饋
提出的修改
上線準備度評估

模板補充：

設計決定：批准或否決了什麼
使用者反饋：討論的關鍵洞察
待定的設計問題：需要迭代的地方
上線標準：剩餘的要求

干係人同步

關注：

彙報的進展
提出的顧慮
給出的批准
需要升級的事項

模板補充：

進展概覽：整體進度
已獲批准：拿到的簽字確認
升級事項：提給干係人的問題
下次同步：時間和內容

會議紀要示例

# 產品路線圖評審：2026 年第一季度
**日期**：2026 年 1 月 20 日
**參會人**：Sarah（CPO）、Mike（技術負責人）、Jennifer（設計）、Tom（產品經理）
**記錄人**：Tom
**時長**：45 分鐘

## 議程
- [x] 評審第一季度計劃的功能
- [x] 討論資源限制
- [x] 優先順序討論
- [x] 時間線對齊

## 已做出的決定

**決定**：多渠道工作臺移到第二季度，第一季度優先改進移動端 App
**背景**：客戶反饋顯示移動端體驗嚴重影響留存（65% 的使用者主要使用移動端）。工程團隊本季度只能承擔一個重大專案。
**負責人**：Tom（產品經理）負責向干係人溝通
**截止日期**：1 月 22 日

**決定**：拿出 20% 的工程時間處理技術債
**背景**：累積的技術債正在拖慢功能開發。上季度團隊速率下降 30%。
**負責人**：Mike（技術負責人）建立技術債待辦列表
**截止日期**：1 月 27 日

**決定**：全量上線前先對 100 名使用者做移動端內測
**背景**：需要在不同裝置上驗證改進效果
**負責人**：Jennifer（設計）與測試團隊協調
**截止日期**：2 月 10 日

## 待辦事項
- [ ] **按新優先順序更新第一季度路線圖** - @Tom - 截止：1 月 22 日
- [ ] **與客服團隊約會議，溝通工作臺延期** - @Tom - 截止：1 月 24 日
- [ ] **制定技術債優先順序評分標準** - @Mike - 截止：1 月 27 日
- [ ] **對移動端設計做使用者測試** - @Jennifer - 截止：2 月 3 日
- [ ] **為高管寫清決策理由** - @Sarah - 截止：1 月 23 日
- [ ] **找到 100 名移動端內測使用者** - @Tom - 截止：2 月 1 日

## 討論要點

**第一季度功能優先順序**
- 客戶留存是本季度公司的第一優先順序
- 移動端 App 的 NPS 為 6.2（網頁端為 8.1）
- 移動端佔日活使用者的 65%
- 多渠道工作臺需要 8 個工程周
- 移動端改進估計需要 6 個工程周，回報更高
- 銷售有 3 個企業客戶訂單在等工作臺功能

**資源限制**
- 目前有 4 名工程師可用（上季度為 6 名，因人員流失減少）
- 設計團隊可以同時支援兩個專案，但產能下降
- 測試團隊需要 2 周對移動端做完整測試
- 一名工程師借調到安全團隊直到 2 月

**風險討論**
- 推遲工作臺可能影響企業銷售（3 個訂單在等）
- Sarah 指出："我們可以把移動端改進定位為企業功能的基礎"
- Mike 對移動端技術棧的穩定性表示擔憂，已透過技術債時間分配解決
- 需要就時間線變化與銷售清楚溝通

**移動端實施計劃**
- 第 1 到 2 周：根據使用者反饋細化設計
- 第 3 到 4 周：工程實現
- 第 5 周：內部測試
- 第 6 周：100 名使用者內測
- 第 7 周：全量上線

## 待解決問題
- **問題**：推遲工作臺對企業銷售管道有什麼影響？
  **負責人**：Sarah 向銷售負責人確認
  **截止**：1 月 23 日

- **問題**：能否為企業客戶做工作臺的有限內測？
  **負責人**：Tom 與 Mike 探討 MVP 範圍
  **截止**：1 月 25 日

- **問題**：如果移動端改進沒有達到目標指標，我們的計劃是什麼？
  **負責人**：Tom 制定應急方案
  **截止**：1 月 27 日

## 下一步
1. Tom 在週三（1 月 22 日）下班前把更新後的路線圖發給領導層
2. 團隊下週一（1 月 27 日）開始移動端改進的迭代規劃
3. 2 月 1 日開跟進會，檢查進展並驗證優先順序
4. Sarah 在 1 月 24 日向高管團隊彙報決策理由

---

**下次會議**：2026 年 2 月 1 日，進展檢查
**紀要發出時間**：2026 年 1 月 20 日 17:30

延伸材料

這個技能附帶支援檔案，可用時請使用：

references/decisions-vs-discussion.md：區分決定與討論。在產出時應用它；它包含上面方法摘要壓縮掉的校準和判斷。
templates/notes-skeleton.md：可填寫的成果模板，品質關卡寫在裡面。當使用者想自己完成文件而不是生成時提供。

評分量表（0 到 40）

交付前給這個技能的任何產出打分；32 分以上才算可以交付。

維度	0	5	10
待辦問責	待辦分給"團隊"或沒人負責，沒有日期	有負責人，但截止時間含糊（"下週"、"儘快"）或多人共擔	每個待辦都有且只有一個負責人和明確日期；共同的工作拆成分別負責的事項
決定可追溯	決定埋在討論裡，或記錄了卻沒有理由	列出決定和負責人，但理由單薄；分歧看不到	每個決定都有背景、負責人和截止日期；反對意見記錄在決定中並附重新討論的條件，而不是被抹平
提煉而非記錄	按順序逐字記錄誰說了什麼	按議題整理的精簡記錄，但仍是對話而不是提煉	討論被提煉為承重的要點；只有在影響決定時才引用原話
閉環	待解決問題、推遲的議題和升級被悄悄丟掉	列出了待辦，但沒有負責人或日期；推遲的事從下一步中消失	每個待解決問題都有負責人和截止時間；推遲的事帶日期出現在下一步中；紀要在 2 小時內發出

品質檢查

每個待辦都有一個具名負責人（不是"團隊"）
每個待辦都有明確截止日期
決定包含背景（為什麼這樣決定）
待解決問題有負責人和截止時間
沒有逐字記錄，只有提煉

反模式

不要把待辦分給"團隊"或"大家"：每個待辦必須有且只有一個具名負責人，否則不會完成
不要逐字記錄對話：會議紀要記錄的是決定和承諾，而不是達成它們的完整對話過程
不要省略決定的背景：六個月後有人問"我們為什麼這麼做"時，沒有理由的決定毫無用處
不要讓待解決問題沒有負責人和截止日期：沒人跟進的問題就是被卡住的決定
不要在會後超過 2 小時才發紀要：第二天才發，負責人就錯過了趁熱行動的視窗

紀要分發

郵件標題格式："[會議型別] 紀要 - [日期] - [關鍵議題]"

示例："產品路線圖評審紀要 - 1 月 20 日 - 第一季度優先順序"

收件人：

所有參會人
待辦中提到的任何人
任何要求收到紀要的人

跟進：

在待辦截止前 3 天發提醒
每週彙總所有未完成的待辦
把完成的待辦標記出來並同步進展

執行

供已連線 MCP 服務（Notion、Linear / Jira、Slack）的工具型智慧體使用。沒有工具許可權的執行環境忽略這一部分，只交付文件。參見 SKILLSPEC.md §5 和 connectors/mcp-pairings.md。

前提條件

上面的結構化紀要已經展示給使用者並得到明確批准，包括目的地（哪個 Notion 資料庫或頁面、哪個任務跟蹤專案）。
MCP 服務已在智慧體的環境中連線並完成認證。
每個待辦都有具名負責人：沒有負責人的事項先與使用者確認，絕不憑猜測分配。

允許的操作

在批准的 Notion 資料庫（或同類文件工具）中建立一個頁面，內容為批准的紀要原文。
在批准的專案中為每個批准的待辦建立一個任務（標題、負責人、截止日期來自紀要）。
如果使用者指定了頻道，把頁面連結（只有連結和一句摘要）發到該頻道。
其他一律不做：不編輯已有頁面或任務，不邀請或通知指定頻道之外的人，不寫入日曆。

驗證

讀取建立的頁面和每個建立的任務；確認標題、負責人和日期與批准的紀要一致。
把所有建立的連結用一個列表報告給使用者。

回滾

撤銷 = 只在使用者明確指示時，歸檔或刪除剛建立的頁面和任務。
遇到以下情況，停下來問使用者：找不到目標資料庫或專案、任務建立中途失敗（報告已經建立了什麼）、待辦負責人在任務系統中不存在。

示例觸發語

“幫我整理會議紀錄。”
“把討論筆記整理一下。”
“列出待辦事項。”
“記錄這次會議的決議。”