这个 Skill 处理的是会前准备。你提供会议目的、参会人、时长以及需要做出的决定，它从 Notion 里寻找相关纪要、规范和遗留事项，再按状态同步、决策、规划或复盘等类型组织材料。与会者因此可以先读背景，把会议时间留给真正需要讨论的部分。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer notion-meeting-intelligence
- 本地 Codex 与可用的 Notion MCP 连接
- 已通过 OAuth 授权的 Notion 工作区
- 目标页面或数据库的访问与编辑权限
若尚未连接，在 ~/.codex/config.toml 中加入下面配置，然后在终端运行 codex mcp login notion 完成 OAuth。当前 Notion 文档不要求旧 Skill 中的 rmcp_client 开关。已安装可用 Notion 连接时无需重复配置。 [4]
[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"
第一次怎么用
替换目标 Notion 页面链接后，可以这样开始：
$notion-meeting-intelligence
为周四 30 分钟的支付改版决策会准备材料。参会人是产品、后端和客服负责人，目标是决定先上线哪一种退款入口。背景页：[粘贴链接]。读取上一轮纪要和未完成事项，给出预读摘要、议程时间分配、待决定问题。不要编造参会人的观点；先在对话里预览。
接下来怎样推进
-
说清这场会要决定什么。 补齐时间、参会角色、必须输出的决定，以及哪些话题不在本次范围。
-
找出前情与阻碍。 读取上次纪要、需求和未结任务，区分已有事实、各方观点与缺失信息。外部补充材料需另附链接。
-
编排议程。 按会议类型设置讨论顺序，为每项标出时间、主持人或待指定负责人，以及预计产出。确认目标页面后再写入。
用会前材料减少会议里的背景复述
把会议类型、时间、参会角色和必须做出的决定写在请求里，同时给出上次纪要或项目入口。例如：“准备下周的发布决策会，目标是决定是否按原定日期上线；先读取最近两次纪要和仍未关闭的高优先级问题，形成 30 分钟议程与预读。” Agent 可以据此把事实、未解决的风险和需要现场判断的问题分开，而不是生成通用的开场、讨论、总结模板。
一份可用的议程应让每个条目都有目的、时间盒和预期产出。需要某位负责人提供数据时，标为待确认，不替对方承诺。若 Notion 搜索出了同名项目，先看页面所属团队和日期；过去项目的“已解决”结论不能自动套用到本次会议。
会前最后一遍核对
打开生成页面，确认预读链接可访问、议程总时长正确、决策问题可以用现有材料回答。没有资料支持的判断应保留为问题。Skill 整理会议材料，不会自动创建日历邀请、通知参会人或代表他们同意某个决策。
另一个场景：故障复盘会
复盘会与发布决策会的议程不同。可以说：“从上次故障纪要和未结行动项准备 45 分钟复盘；先梳理已确认时间线与影响，再列出需要当场决定的监控、值班和回滚问题。不要把尚未核对的根因写成事实，也不要预先给负责人分配任务。” 验收时看议程是否给事实澄清留时间，预读是否指向原始事件与行动项，会议后需要填写的决定和负责人是否留有位置。资料缺失时，明确写成会前待补，不应生成一份貌似完整的时间线。
交付后先检查什么
材料应包括简短背景、可提前阅读的链接、时间总和合理的议程，以及明确的决策题。对照邀请名单检查每位参会人为什么需要到场；没有来源的市场判断不应混入项目事实。
内部预读与对外议程分开
如果会议既有内部背景，又有外部参与者，先做只供团队看的预读：包括尚未确认的风险、内部讨论与责任人。另做一份可共享议程，只保留目标、时间安排、待讨论问题和对外可说的材料。生成后按分享对象逐项检查权限与敏感信息，不能把内部预读直接发给外部参会者。
常见卡点
会议主题太大。 先缩到一次会议可完成的决定，其余内容移到预读或后续议题。
旧纪要有矛盾。 保留不同日期的结论，列出需要会议确认的变化，不自行宣布哪个版本有效。
没给数据库位置。 先产出对话草稿；明确落点后再创建页面，避免材料散落。