decision-logger

decision-logger skill 概览

decision-logger 能做什么

decision-logger 是一个 Decision Support skill，用于把董事会会议结果沉淀为可长期使用的双层决策记忆。第 1 层保留原始会议上下文；第 2 层只保存已批准的决策、负责人、截止日期、被否决选项和后续事项。它的价值很务实：未来由 AI 辅助的会议应基于已经确认的决策，而不是未解决的争论或被 AI 臆造出来的“共识”。

最适合董事会和高管会议流程

decision-logger skill 最适合创始人、Chief of Staff、董事会运营负责人，以及支持周期性高管会议的 AI agent。它适用于那些需要让决策跨会议延续、后续可搜索，并且要与讨论笔记分开的工作流。尤其是在类似 board-meeting 的流程中，会议结果经过创始人批准后，需要形成一份干净、可审计记录的场景。

关键差异：只保留已批准的记忆

它最有价值的设计，是把原始 transcript 和已批准的 Layer 2 index 明确分开。未来复盘时读取的是已批准层，而不是会议中每一个论点。这有助于避免过去已经被否决的想法，后来又像仍然可行一样被重新提出。模板还包含 DO_NOT_RESURFACE、替代/覆盖字段、review dates 和 owner tracking，因此它比普通的“总结会议纪要”prompt 更偏运营化。

安装前需要确认什么

采用 decision-logger 之前，请先确认团队愿意维护本地决策索引：~/.claude/decisions/approved/decisions.md。随附的 Python helper 会读取这个文件，并能报告逾期事项、冲突、按负责人筛选的行动项和关键词搜索。如果你的流程目前并不区分“已批准决策”和“讨论笔记”，可能需要先调整会议工作流。

如何使用 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 条目格式。
3. scripts/decision_tracker.py — 提供 summary、overdue items、conflicts、owner filters 和 search 等报告命令。

该脚本只使用 Python standard library，因此除了本机可用 Python 之外，不需要额外配置依赖。

让 skill 发挥效果所需的输入

要让 decision-logger 用得好，不要只给 agent 一段粗略会议摘要。应提供 agenda item、最终批准的 decision、accountable owner、due date、review date、rationale、rejected alternatives，以及任何 founder override。模板预期每个条目只记录一个决策，所以如果会议结果里打包了多个决策，需要拆成独立记录。

较弱输入：“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 中保存或引用原始 transcript。
2. 要求 agent 只提取创始人已批准的结果。
3. 使用 templates/decision-entry.md 创建 Layer 2 条目。
4. 为被否决的选项标注原因和 DO_NOT_RESURFACE。
5. 运行 tracker script，检查 summaries、overdue actions 或 conflicts。

repository 中有用的命令包括：

• 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

生成更好条目的 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 决策记忆设计的，但也可以用于投资委员会、领导层 staff meeting、产品委员会或治理评审。关键前提是：决策需要被正式批准，并且需要后续跟进。对于没有形成最终决策的头脑风暴会议，它的价值会低很多。

它为什么比让 AI 总结会议纪要更好？

普通总结往往会把讨论、建议、反对意见和决策混在一起。decision-logger 强制结构化：已批准决策、负责人、截止日期、决策依据、被否决选项、行动项、替代/覆盖关系，以及原始 transcript 链接。正是这种结构，支持后续复盘、逾期检查和冲突检测。

decision-logger skill 需要数据库吗？

不需要。repository 中的证据显示，它采用基于 markdown 的存储方式，并配有一个只依赖 Python standard-library 的脚本。主要的 Layer 2 index 预期位于 ~/.claude/decisions/approved/decisions.md，同时通过 --file 兼容另一个 legacy file path。这让它很轻量，但如果团队需要多用户权限、dashboard 或 audit logs，可能还需要额外工具。

什么时候不适合使用 decision-logger？

不要把它当成所有会议笔记的倾倒场。如果决策总是在变化、没有明确 owner 或日期，或者组织无法辨认到底什么才算“已批准”，它也不太适合。在这些情况下，先使用 meeting-notes skill 或项目管理集成，可能比直接增加决策记忆更合适。

如何改进 decision-logger skill

用更清晰的批准口径提升 decision-logger 结果

最重要的质量因素是批准口径是否清楚。记录前请核对：到底决定了什么？谁负责？什么时候完成？哪些内容被明确否决？未来的 agent 应避免再次提出什么？如果其中任何一项缺失，应先追问，而不是创建一个含糊的条目。

需要避免的常见失败模式

注意避免这些条目：一个段落里塞进多个决策；多人共同负责但没有唯一 accountable person；截止日期写成“soon”；rationale 只是重复决策本身；被否决的想法没有说明原因。这些都会削弱之后的搜索和复盘效果。模板里的字段规则应被当作约束，而不是建议。

在第一版生成后继续迭代

agent 起草条目后，要像审阅运营记录一样检查它。把 decision 收敛成一句话；将人名或角色整理为单一 owner；把相对日期替换为 YYYY-MM-DD；确保 action items 可以被检查。然后运行 --summary、--overdue 或 --conflicts，验证该条目在 tracker 中表现正常。

按你的运营模型扩展 skill

团队可以通过增加一致的 agenda tags、board committee labels、risk level、decision type，或指向 project tickets 的链接来改进 decision-logger。扩展时要保持与 markdown index 兼容，并避免添加没人会维护的字段。目标不是为了文档更丰富而丰富，而是让下一次会议获得更干净的 Decision Support。