decision-logger

decision-logger skill 概覽

decision-logger 的用途

decision-logger 是一個 Decision Support skill，可將董事會會議結果整理成可長期保存的雙層決策記憶。Layer 1 保留原始會議脈絡；Layer 2 只存放已核准的決策、負責人、期限、被否決的選項，以及後續追蹤事項。它的重點很務實：未來由 AI 輔助的會議應該依據已確認的決策，而不是尚未定論的討論或被幻覺出來的共識。

最適合董事會與高階主管工作流程

decision-logger skill 最適合創辦人、幕僚長、董事會營運人員，以及支援定期高階會議的 AI agents。它適用於這類工作流程：決策需要跨會議延續、日後可搜尋，並且必須和一般討論筆記分開保存。當 board-meeting 類型的流程以創辦人核准作結，接著需要一份乾淨、可稽核的紀錄時，它特別有用。

主要差異：只保留已核准的記憶

這個 skill 最有力的設計選擇，是把原始逐字稿和已核准的 Layer 2 index 分開。未來回顧時讀取的是已核准層，而不是會議中的每一段爭論。這能避免過去已被否決的想法，日後又像仍然可行一樣被重新提出。範本也包含 DO_NOT_RESURFACE、取代關係欄位、review dates，以及 owner tracking，讓它比一般「摘要會議筆記」prompt 更具營運實用性。

安裝前該檢查什麼

採用 decision-logger 前，請先確認團隊能接受在本機維護一份 decision index：~/.claude/decisions/approved/decisions.md。內附的 Python helper 會讀取這個檔案，並可回報逾期項目、衝突、特定 owner 的行動項，以及關鍵字搜尋結果。如果你的流程目前沒有把已核准決策和討論筆記區分開來，可能需要先調整會議工作流程。

如何使用 decision-logger skill

decision-logger 安裝方式與優先檢查的檔案

從 repository path 安裝 skill：

npx skills add alirezarezvani/claude-skills --skill decision-logger

安裝後，請依序閱讀以下檔案：

1. SKILL.md — 說明雙層記憶模型、slash-command 的意圖，以及預期的儲存位置。
2. templates/decision-entry.md — 展示 Layer 2 entry 的精確格式。
3. scripts/decision_tracker.py — 提供 summary、逾期項目、conflicts、owner filters，以及 search 的報告指令。

這個 script 只使用 Python standard library，因此除了要有可用的 Python 之外，不需要額外設定依賴套件。

skill 要運作得好，需要哪些輸入

若要讓 decision-logger 發揮效果，不要只給 agent 一段粗略的會議摘要。請提供 agenda item、最終已核准的 decision、accountable owner、due date、review date、rationale、rejected alternatives，以及任何 founder override。範本預期每筆 entry 只記錄一個 decision，因此若會議結果包含多個決策，請拆成不同紀錄。

弱輸入：「Log that we discussed pricing and decided to test something。」

較佳輸入：「Log the approved decision from the 2026-03-05 board meeting: move from flat pricing to a three-tier pilot for new customers. Owner: CRO. Deadline: 2026-04-15. Review: 2026-05-01. Rationale: improves expansion path while limiting migration risk. Rejected: immediate migration of all existing customers because support load is too high. Raw transcript path: ~/.claude/decisions/raw/2026-03-05-pricing.md。」

會後的實務工作流程

請在決策獲得核准後使用 decision-logger，而不是在開放式辯論進行中使用。可靠的流程如下：

1. 在 Layer 1 儲存或引用原始逐字稿。
2. 要求 agent 只擷取創辦人已核准的結果。
3. 使用 templates/decision-entry.md 建立 Layer 2 entry。
4. 將被否決的選項標上原因與 DO_NOT_RESURFACE。
5. 執行 tracker script，檢查 summaries、逾期 actions，或 conflicts。

repository 中實用的 commands 包含：

• python scripts/decision_tracker.py --demo
• python scripts/decision_tracker.py --summary
• python scripts/decision_tracker.py --overdue
• python scripts/decision_tracker.py --conflicts
• python scripts/decision_tracker.py --owner "CTO"
• python scripts/decision_tracker.py --search "pricing"
• python scripts/decision_tracker.py --due-within 7

產生更好 entries 的 prompt 模式

好的呼叫方式應該要求產出 decision entry，而不是敘事型摘要。例如：

「Use the decision-logger skill to create a Layer 2 approved decision entry. Include one clear decision statement, one accountable owner, deadline, review date, rationale, rejected proposals with DO_NOT_RESURFACE, action items, supersedes fields if applicable, and the raw transcript path. Do not include unapproved discussion points.」

這樣的框架能降低模糊性，並讓 Layer 2 保持乾淨，方便日後用於 Decision Support。

decision-logger skill 常見問題

decision-logger 只適合董事會會議嗎？

它是以董事會與 C-level 決策記憶為核心設計，但也可用於投資委員會、主管例會、產品委員會，或治理審查。關鍵條件是：決策必須經過正式核准，並且需要後續追蹤。若是沒有最終決策的腦力激盪會議，它的幫助就比較有限。

這和請 AI 摘要會議紀錄有什麼不同？

一般摘要常會把討論、建議、反對意見和決策混在一起。decision-logger 強制採用結構化格式：已核准決策、owner、deadline、rationale、rejected options、action items、supersession，以及 raw transcript link。正是這種結構，讓後續回顧、逾期檢查與衝突偵測成為可能。

decision-logger skill 需要資料庫嗎？

不需要。從 repository 內容來看，它採用 markdown-based storage，並搭配一個只使用 Python standard-library 的 script。主要的 Layer 2 index 預期位於 ~/.claude/decisions/approved/decisions.md，也透過 --file 對另一個 file path 提供 legacy support。這讓它很輕量；但如果團隊需要多使用者權限、dashboards，或 audit logs，可能還需要額外工具。

什麼情況下不該使用 decision-logger？

不要把它當成所有會議筆記的傾倒區。如果決策經常變動、沒有 owner 或日期，或組織無法辨識實際上核准了什麼，它也不適合。這些情況下，在加入 decision memory 之前，使用 meeting-notes skill 或 project-management integration 可能更合適。

如何改進 decision-logger skill

用更清楚的核准結果改善 decision-logger 成效

最重要的品質因素是核准內容是否清楚。記錄前請確認：到底決定了什麼？誰負責？期限是什麼時候？哪些內容被明確否決？未來 agents 應避免重新提出什麼？如果其中任何一項缺失，應先追問，而不是建立一筆模糊的 entry。

需要避免的常見失敗模式

請留意這些問題：一個段落塞入多個 decisions、多人共同負責但沒有 accountable person、deadline 寫成「soon」、rationale 只是重述 decision，或 rejected ideas 沒有附理由。這些都會削弱日後搜尋與回顧的效果。範本中的欄位規則應被視為限制條件，而不是建議。

第一版 entry 產生後繼續修訂

agent 起草 entry 後，請像審查營運紀錄一樣檢視它。把 decision 收斂成一句話，將人名或角色整理成單一 owner，把相對日期改成 YYYY-MM-DD，並確認 action items 可以被檢查。接著執行 --summary、--overdue 或 --conflicts，確認這筆 entry 在 tracker 中能正常運作。

依你的營運模型擴充 skill

團隊可以透過加入一致的 agenda tags、board committee labels、risk level、decision type，或 project tickets 連結來改善 decision-logger。擴充時請維持與 markdown index 相容，並避免新增沒有人會維護的欄位。目標不是為了文件更豐富而豐富，而是讓下一次會議能取得更乾淨的 Decision Support。