Meeting Digest
工具： 步驟會呼叫角色操作（
pm.*、email.*、calendar.*、docs.*、files.*、comms.*）。請透過Context/agent-config.md→ 工具堆疊 及其命名的適配器（.claude/adapters/README.md）來解析每個角色。設為none的角色 → 跳過該步驟。
擷取指定日期的所有會議，尋找每場會議的筆記或逐字稿，產出結構化摘要，並儲存在本機。預設目標日期為今天；傳入「yesterday」則處理前一天。
設定
開始時先讀取 Context/agent-config.md。使用：
timezone— 用於所有日期計算base_directory— 用於檔案路徑建構與冪等性檢查calendar_exclusions— 要跳過的會議標題模式清單- 工具堆疊 → 會議筆記 — 會議內容的來源
讀取目標檔案（路徑在 agent-config 中）以在步驟 4 中識別專案與里程碑名稱。
指令
依序執行所有步驟。除非明確告知暫停，否則不要在步驟之間要求確認。
步驟 1 — 擷取指定日期所有未摘要的會議
階段 A — 日曆：取得會議清單
-
在使用者的時區內計算目標日期。預設 = 今天；如果使用者傳入「yesterday」，減去一天。
-
在使用者的時區內呼叫
calendar.events(目標日期開始, 目標日期結束)。 -
過濾為真正的會議。 移除任何符合以下條件的事件：
summary符合calendar_exclusions中的某個模式- 是專注時間或工作地點區塊
attendees清單為空或只包含使用者本人（獨自區塊）
-
按時間排序（最早的在最前）。這是待處理會議的排序清單。
階段 B — 冪等性檢查
針對每場會議：
- 推導預期的筆記檔名：
YYYY-MM-DD - [會議名稱].md，使用日曆事件的summary。清理名稱：將/、\、:和|替換為-，移除表情符號，合併連續空格。 - 檢查
[base_directory]/Context/Meeting Notes/中是否已存在該名稱的檔案。 - 如果存在且已有
## Summary區段 → 跳過此會議。輸出："[會議名稱] 的筆記已存在——跳過。" - 如果存在但為原始筆記（無
## Summary）→ 將其內容作為來源並繼續。 - 如果不存在 → 繼續到階段 C。
階段 C — 尋找會議內容
依序檢查以下來源，使用第一個有內容的來源：
- 原始筆記檔案 — 來自階段 B 步驟 4。
- 已設定的來源 — agent-config → 會議筆記來源 中的每個項目，依序進行。常見項目：
- 日曆附件 — 附加在事件上的筆記文件 → 使用其檔案 ID 呼叫
files.read。「找不到」表示該文件未與使用者共用——靜默跳過 docs.meeting_notes(date)— 依標題或時間視窗（±30 分鐘）比對；使用docs.read讀取
- 日曆附件 — 附加在事件上的筆記文件 → 使用其檔案 ID 呼叫
- 日曆事件描述 — 僅在包含真實筆記（不只是議程或視訊連結）時使用。
- 詢問使用者 — 在一則訊息中列出所有仍無內容的會議："找不到以下會議的筆記：[清單]。請貼上任何您想要摘要的筆記或逐字稿，或說跳過。"
如果某場會議仍無內容 → 標記為 "無可用筆記" 並跳過。
階段 D — 報告
處理完所有會議後，報告：
- 摘要了多少場
- 跳過了多少場（附原因：已存在 / 無筆記）
步驟 2 — 讀取背景資訊
在處理任何筆記內容之前，先讀取：
GOALS.md— 了解活躍中的專案與目標Context/Memory/brain.md— 了解使用者的思考方式、詞彙，以及他們如何區分決策與討論
步驟 3 — 分析筆記內容
對於有內容的每場會議，提取四項資訊：
A. 總結 2–3 句話。結果優先：會議主旨與關鍵成果或轉變。不是主題列表——而是單一連貫的結果陳述。使用使用者的語氣：直接、無刻意框架、以結果為開頭。
B. 決策 改變方向、鎖定某項決定或關閉懸而未決問題的明確承諾。僅限真正的決策——不是建議或可能選項。格式：決定了什麼，以及由誰拍板（如果可以歸因）。
C. 行動項目 有指定負責人的具體下一步。對每個項目套用以下邏輯：
- 如果筆記高度確定指出特定人員為負責人 → 指派給該人員
- 如果負責歸屬不明確或共同負責 → 指派給使用者
- 僅在會議中明確提及的專案管理項目或專案才納入（透過按鍵、名稱或明確參照）。不要推斷或猜測——如果沒有提及，專案欄位留白（
—） - 如果會議中提及建議的截止日期則標註，否則留白
D. 未解決問題 / 障礙 未解決的問題、提出的障礙，或留待未來會議討論的主題。這些僅放入筆記檔案中。
步驟 4 — 專案參照
僅在會議中明確提及的項目按鍵或專案名稱才記錄——透過按鍵（例如 ENG-123）、名稱（例如「入職改造里程碑」）或明確參照。
不要從會議背景推斷、查詢或猜測專案。留白比錯誤指派更好。
步驟 5 — 寫入會議筆記檔案
將摘要儲存到 Context/Meeting Notes/，使用以下檔名格式：
YYYY-MM-DD - [會議名稱].md
使用日曆事件的 summary 作為會議名稱。
檔案格式：
# [會議名稱]
*[YYYY-MM-DD] | [持續時間（如有）] | [來自日曆的與會者（如有）]*
## Summary
[2–3 句結果優先的總結。發生了什麼以及什麼改變了。]
## Decisions
- [決策 1 — 若知道由誰決定]
- [決策 2]
## Action Items
| # | 任務 | 負責人 | 專案 | 截止日期 |
|---|------|--------|------|----------|
| 1 | [任務描述] | [姓名 / 我] | [專案名稱 (KEY-123) 或 —] | [日期或 —] |
| 2 | ... | ... | ... | ... |
## Open Questions & Blockers
- [問題或障礙 — 什麼尚未解決以及為何重要]
## Context
[來自會議的任何背景資訊、連結或脈絡，對未來參照有幫助。最多 3–5 個要點。]
如果來源是原始筆記（階段 B 步驟 4），在 ## Raw notes 區段下方保留它們——絕不刪除使用者的筆記。
在儲存之前，為筆記加入 [[wiki-links]] 以實現 Obsidian 圖譜連線：
- 所有被提及姓名的人 →
[[姓名]] - 所有項目按鍵 →
[[KEY-123]] - 在不同筆記中重複出現的關鍵概念、專案與主題 →
[[概念]] - 僅連結有意義的提及——不是每個詞，不在程式碼區塊或網址內部
向使用者確認："會議筆記已儲存到 Context/Meeting Notes/[檔名].md"
步驟 6 — 觸發式連動
儲存後：
- 檢查本次會議的任何決策或障礙是否與
Tasks/中的未完成任務相關——如果是，在內文中註明。 - 如果提出的障礙已存在於
GOALS.md中作為已知障礙，標記出來："此障礙 ([名稱]) 也曾在 [先前的背景] 中被提出。請考慮是否為系統性問題。" - 如果會議是與特定人員的定期一對一，且該人員在
Context/121s/中有文件，則在該文件中附加一筆會議記錄：日期、一行總結、新增的任何未結事項。
會議筆記包含個人資料，絕不提交或推送。
步驟 7 — 在對話中顯示摘要
在所有筆記儲存完成後，顯示當天完整摘要的合併報告。
結構：會議 → 主題 → 各主題下的決策 + 行動項目。
📝 **會議摘要完成 — [YYYY-MM-DD]** | [N] 場已摘要 | [N] 場已跳過
*[會議名稱]*
[主題 / 目標或里程碑]
決策
- [決策]
- [決策]
行動項目
- [任務] → [負責人] [截止日期（如有）]
[主題 2]
決策
- [決策]
行動項目
- [任務] → [負責人]
筆記已儲存到 `Context/Meeting Notes/`
分組規則：
- 第一層：會議名稱
- 第二層：會議中討論的主題、目標或里程碑——使用純文字名稱，絕不使用單純的 issue 按鍵
- 第三層：決策 和 行動項目 作為各主題下的標籤式子區段
- 如果一個主題沒有決策，省略「決策」子區段。如果沒有行動項目，省略「行動項目」子區段。
- 如果一場會議只有一個主題，仍顯示主題名稱——不要摺疊
- 在對話摘要中省略行動項目的「專案」欄——該欄位僅屬於筆記檔案
步驟 8 — 提供決策日誌更新選項
此步驟僅在至少從所有已摘要會議中提取出一項決策時執行。
只詢問一次，在單一訊息中：
"要將任何這些決策記錄到 PRD 的決策日誌嗎？
今日決策：
[會議名稱] [主題] 1. [決策] 2. [決策]
如果要，請告訴我要更新哪份文件（
Context/Document Hub/中的本機檔案，或 docs 工具中的頁面）以及要加入哪些決策編號。"
跨所有會議依序編號決策，方便使用者使用編號參照。
等待使用者回應。
- 如果不 / 跳過：結束技能。
- 如果要：針對使用者指定的每份文件執行以下步驟。
針對每份提供的文件：
A. 擷取文件
- 本機檔案 → 讀取。
- Docs 工具頁面 →
docs.read。
B. 找到決策日誌
掃描標題包含「Decision Log」、「Decisions Log」或「Decisions」（不區分大小寫）的區段。
- 如果存在含有表格的 Decision Log 區段：將新行附加到表格中。
- 如果存在 Decision Log 區段但沒有表格：在標題下方立即插入表格。
- 如果不存在 Decision Log 區段：在文件底部插入新的
## Decision Log區段與表格。
C. 建立行
針對使用者選擇的每項決策，建立一個表格行：
| [YYYY-MM-DD] | [決策文字] | [狀態] |
- 日期：會議日期。
- 決策：從摘要中直接複製的文字——不要改寫。
- 狀態：如果明確且為最終決定，則為
Decided。如果文字包含「TBD」、「to be confirmed」、「pending」、「waiting on」，或標記為未解決，則為Pending。
如果表格尚不存在，先建立包含表頭行的表格：
| Date | Decision | Notes/Status |
|------|----------|--------------|
D. 預覽，然後更新
顯示要加入的行。如果是本機檔案，直接寫入。如果是 Docs 工具頁面，等待使用者明確同意，然後呼叫 docs.update(ref, "Decision Log", rows) — 只更改該區段。
E. 確認
"Decision Log 已更新於 [文件標題] — 已加入 [N] 項決策。"
邊緣案例
- 未找到決策：寫入「未做出任何決策——屬於討論／更新性質的會議。」不要憑空捏造決策。
- 未找到行動項目：寫入「無行動項目。」
- 會議是每日站會或 <5 分鐘：仍執行摘要，但總結僅限一句話。
- 多個筆記對應同一事件：使用最接近事件開始時間的那一個。
- 來源不可用：靜默跳過，並在階段 C 中繼續到下一個來源。
- Docs 頁面找不到（步驟 8）：回報錯誤，請使用者再次確認 URL，並提供重新嘗試的選項。
- Decision Log 區段不明確（步驟 8）：如果有多個標題可能符合（例如「Key Decisions」和「Decision Log」），顯示兩者並詢問要附加到哪一個。
- 重複決策（步驟 8）：在插入之前，掃描現有行。如果相同的決策文字已經存在，跳過並註明已跳過。