需求文档写完之后，仍要有人把“要做什么”拆成可推进的工作。notion-spec-to-implementation 读取指定规格，提取验收条件和约束，建立计划页及任务库记录，并把需求、计划、任务连起来，适合项目准备和持续进度整理。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer notion-spec-to-implementation
- 本地 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-spec-to-implementation
把这份 PRD [粘贴链接] 拆成实现计划，任务库是 [粘贴链接]。先列需求、验收条件、依赖和待澄清点；把任务控制在约 1–2 天可完成的范围，但估时仅作建议。先展示计划和任务列表，确认后创建关联记录；不要编造负责人或截止日期。
接下来怎样推进
-
先读规格。 提取功能要求、优先级、验收标准和限制；含糊部分先列问题，避免它们被直接变成实现假设。
-
安排阶段与任务。 简单改动用短计划，跨系统需求拆阶段；每项任务写清目标、输入、验收与依赖。
-
写入并维持关联。 确认任务库真实属性后创建记录，让规格、计划、任务互相链接。后续按实际完成情况更新状态和阻碍。
从一页 PRD 拆到可执行任务
先给出确切的 Notion 规格链接和项目任务库，不要只说“把需求拆一下”。可以输入：“把这个用户导出 PRD 转成实现计划。先读验收标准、权限要求和失败状态；列出缺失的决定供我确认。确认后，把任务拆到可在一两天内完成的范围，并关联回 PRD。” 当搜索出现多个同名规格时，先核对更新时间和所属项目，避免旧版需求进入计划。
计划至少说明阶段顺序、跨团队依赖、迁移或回滚点；任务应以动作开头，包含范围、输入、验收条件和所依赖的上游任务。比如“导出 CSV”并不是充分的任务名称：还要说谁可触发、最大数据量、字段格式、失败时用户看到什么，以及如何验证权限边界。估时可以作为讨论起点，不能伪装成团队承诺。
检查 Notion 里的关联
创建后分别打开规格、计划和几条任务，确认双向链接或关系属性指向正确对象，状态与负责人没有被臆造。下一次使用时要求按真实代码进展更新任务，而不是只根据计划生成时的假设移动状态。规划完成不表示功能已经交付。
交付后先检查什么
交付应让你从一条需求找到对应任务，也能从任务回到验收条件。检查依赖先后、重复任务和无人负责的工作；任务显示“完成”应有实际结果支持，不能只因计划生成完毕就勾选。
从现有计划模板选一种
将规格拆任务时，先判断改动是否足够小、依赖是否少，再选简版或标准版实施计划。若照旧示例查找 reference/templates.md 失败，改看安装包里的 quick-implementation-plan.md 与 standard-implementation-plan.md。无论使用哪种模板，任务都应能追溯到原规格中的验收条件，并标出尚待确认的依赖。
常见卡点
PRD 没有验收标准。 先补可观察的成功条件，再安排实现任务。
任务库字段不匹配。 以目标库当前属性为准，确认状态选项和关联字段，不照搬模板。
拆得过细或过大。 以可独立检查的结果重新分组；1–2 天只是原 Skill 的拆分参考，不是工期承诺。