用 notion-spec-to-implementation 技能规划并落地数据库迁移以用户偏好 Schema 重构为例【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills本文是 awesome-codex-skills 仓库中notion-spec-to-implementation技能的完整案例解析。它围绕 examples/database-migration.md 中的用户偏好 Schema 数据库迁移实战演示了如何把一份 Notion 中的技术规格Spec自动转换为可执行的实施计划、任务看板与进度追踪体系适用于 PRD、技术设计文档、迁移/重构类工单的端到端落地。读完本文你将掌握如何用Notion:notion-search/notion-fetch定位并解析 Spec如何按分阶段 双向依赖原则生成实施计划如何把计划拆解为符合验收标准的任务并写入 Notion 任务数据库以及如何在执行阶段持续同步状态、阻断项与里程碑结论。一、技能定位从 Spec 到实现的全链路编排在 SKILL.md 中notion-spec-to-implementation被定义为Turn Notion specs into implementation plans, tasks, and progress tracking; use when implementing PRDs/feature specs and creating Notion plans tasks from them.它的核心价值是把一份躺在 Notion 里的规格文档变成可执行、可追踪、可验收的工程资产产物包括三样东西实施计划页Implementation Plan链接回原始 Spec包含需求摘要、技术方案、分阶段实施步骤、依赖/风险、成功标准任务数据库中的任务Tasks以 12 天为粒度的可执行任务带上下文、验收清单、依赖关系并双向关联 Spec 与 Plan持续的状态更新Progress Tracking随实施进度同步状态字段、里程碑总结与阻断项。SKILL.md 给出的 Quick Start 五步法也是后面数据库迁移案例的骨架1) 用 Notion:notion-search 定位 Spec再用 Notion:notion-fetch 拉取全文 2) 用 reference/spec-parsing.md 解析需求与歧义点 3) 用 Notion:notion-create-pages 创建计划页在 quick 与 standard 两种模板中选择 4) 找到任务数据库、确认 schema再用 Notion:notion-create-pages 创建任务 5) 用 Notion:notion-update-page 维护 Spec ↔ Plan ↔ Task 之间的链接与状态仓库还提供了两类辅助资产reference/目录存放解析模式、计划/任务模板与进度节奏如 spec-parsing.md、standard-implementation-plan.md、task-creation.md、progress-tracking.mdexamples/目录则给出三种典型场景的端到端走读ui-component.md、api-feature.md、database-migration.md。本文的主角就是其中风险最高、也最能体现分阶段实施价值的数据库迁移案例。二、案例背景与初始用户请求数据库迁移案例的初始用户请求是Plan and implement the database migration for user preferences schema这是一个典型的迁移 重构类任务存量系统已运行、数据不能丢、服务不能停。原文将其拆解为以下核心约束现状Current用户偏好以JSONB单列preferences存储目标Target拆分为user_preferences与notification_preferences两张结构化表硬性要求Must maintain迁移期间保持向后兼容性能指标Performance支撑 100 万以上用户、零停机迁移。从 spec-parsing.md 的分类法看这段描述同时包含了功能需求表结构拆分、非功能需求零停机、规模上限与约束条件向后兼容为后续的分阶段计划提供了全部输入。三、完整工作流走读五步把迁移落地到 Notion3.1 第 1 步查找并获取 Spec迁移工程的第一步是找到那份规格而不是凭经验直接开写 SQL。原文给出的调用序列Notion:notion-search → Found User Preferences Schema Migration Spec Notion:notion-fetch → Extracted requirements对应的 Spec 摘要为Migrate from JSON blob to structured schema for better performance and data integrity.从 JSON 大字段迁移到结构化 Schema以换取更优的性能与数据完整性。spec-parsing.md 补充了搜索阶段的容错策略若返回多个结果应询问用户选择哪一个若未找到则应向用户索要页面 URL/ID。这是保证以真实 Spec 为准、不臆造需求的关键一步。3.2 第 2 步解析需求抓取到 Spec 全文后原文把需求提炼为四要素CurrentJSONB preferences列Target独立的user_preferences与notification_preferences两张表Must maintain迁移过程中的向后兼容Performance支持 100 万 用户、零停机。这四项正是后续所有任务验收标准的来源。例如向后兼容会演化为Phase 3 双写模式的验收条件零停机则要求Phase 4 切换读路径时新旧并存、可快速回滚。3.3 第 3 步创建实施计划计划页通过Notion:notion-create-pages写入 Notion原文给出的最小调用Notion:notion-create-pages pages: [{ properties: { title: Implementation Plan: User Preferences Migration }, content: [Full implementation plan with phases] }]迁移计划的精髓在于五阶段推进每一阶段都对应一条独立的工程目标阶段目标关键动作Phase 1建表创建新表并建立索引Phase 2回填从 JSONB 回填存量数据Phase 3双写新旧两套写入并存dual-writePhase 4切读读路径切换到新 SchemaPhase 5下线删除旧 JSONB 列这与 standard-implementation-plan.md 中Overview → Linked Specification → Requirements Summary → Technical Approach → Implementation Phases → Dependencies → Risks Mitigation → Timeline → Success Criteria的模板骨架一脉相承——迁移类工程天然适合先基础、再核心、后收尾的 phased 编排。同时 SKILL.md 也明确指出简单变更用quick-implementation-plan.md多阶段特性/迁移则用standard-implementation-plan.md本案例属于后者。3.4 第 4 步查找任务数据库并创建任务这是从计划到执行的落地点。原文的调用分两小步先定位任务数据库并确认 SchemaNotion:notion-search → Found Engineering Tasks database Notion:notion-fetch → Got schema (Task, Status, Priority, Assignee, etc.)再批量写入任务以data_source_id指向任务集合Notion:notion-create-pages parent: { data_source_id: collection://xyz } pages: [ { properties: { Task: Write migration SQL scripts, Status: To Do, Priority: High, Sprint: Sprint 25 }, content: ## Context\nPart of User Preferences Migration...\n\n## Acceptance Criteria\n- [ ] Migration script creates tables\n- [ ] Indexes defined... }, // ... 4 more tasks ]task-creation.md 详细说明了这一步的规范先搜索任务数据库query: Engineering Tasks再 fetch 数据库 schemacollection://...形式的 data source确认属性名与类型后按parent: { type: data_source_id, data_source_id: collection://tasks-db-uuid }创建页面同时给出了属性设置的约定例如properties: { [Title Property]: Task: [Clear task name], Status: To Do, Priority: [High/Medium/Low], [Project/Related]: [spec-page-id, plan-page-id], Assignee: [Person] (if known), date:Due Date:start: [Date] (if applicable), date:Due Date:is_datetime: 0 }原文为本次迁移生成了5 个任务Write migration SQL scripts编写迁移 SQL 脚本Implement backfill job实现回填任务Add dual-write logic to API在 API 中加入双写逻辑Update read queries更新读查询Rollback plan monitoring回滚计划与监控注意这 5 个任务与五阶段计划的对应关系任务 1 对应 Phase 1 建表任务 2 对应 Phase 2 回填任务 34 对应 Phase 3 双写与 Phase 4 切读任务 5 贯穿全程的可靠性保障。任务标题遵循 task-creation.md 的命名规范——使用动作动词Write / Implement / Add / Update / Rollback具体而非含糊✓ Write migration SQL scripts✗ Add login 这类反例。task-creation-template.md 给出了每个任务正文的推荐结构Context关联 Spec 与 Plan、Description、Acceptance Criteria- [ ]清单、Technical Details、Dependencies、Resources、Progress。3.5 第 5 步跟踪进度任务创建完成后进入持续执行与同步阶段。原文描述为Regular updates to implementation plan with status, blockers, and completion notes.以状态、阻断项与完成备注定期更新实施计划。progress-tracking.md 给出了更细的节奏约定每日更新任务状态变更、进度备注、阻断项、里程碑更新阶段完成、时间线调整、干系人汇报、状态流转更新To Do → In Progress → In Review → Done / Blocked。阶段完成时使用 milestone-summary-template.md日常同步则采用 progress-update-template.md 的六段式Completed Today / In Progress / Next Steps / Blockers / Notes。对迁移类项目进度页还应维护当前阶段 回滚就绪状态这正是任务 5回滚计划与监控持续输出的内容。四、关键产出与成功要素4.1 关键产出Key Outputs原文把本次会话的产物归纳为三件Implementation Plan Page实施计划页已链接回原始 Spec5 Tasks in Database任务数据库中的 5 个任务含依赖关系与验收标准Progress Tracking随工作推进持续更新的进度记录。三者构成Spec → Plan → Tasks → Progress的完整闭环与 SKILL.md 中Link artifacts的要求一致Plan 链接 SpecTasks 同时链接 Plan 与 Spec可选地用Notion:notion-update-page在 Spec 末尾追加Implementation小节回指计划与任务形成双向导航。这一模式在 api-feature.md 中体现得更细——它展示了用command: insert_content_after在 Spec 的 Acceptance Criteria 之后插入 Implementation 摘要的完整调用。4.2 成功要素Success Factors原文提炼了 5 条经验它们是迁移类任务可复用的方法论将复杂迁移拆解为清晰阶段Broke down complex migration into clear phases为任务定义具体的验收标准Created tasks with specific acceptance criteria建立阶段间依赖Established dependenciesPhase 1 → 2 → 3 → 4 → 5零停机方案并配套回滚计划Zero-downtime approach with rollback plan所有工作均回链原始 SpecLinked all work back to original spec。其中第 3 点直接对应 task-creation.md 的依赖链模式Dependency Chain PatternTask A 建表 → 阻塞 Task B 回填 → 阻塞 Task C 双写 → 阻塞 Task D 切读第 2 点对应其验收标准必须可测试的要求✓ Page loads in 2 seconds✗ System is fast第 5 点则与 evaluations/README.md 中Tasks link back to spec using mention-page tag的验收口径完全吻合。五、环境准备Notion MCP 连接上述所有Notion:notion-search/notion-fetch/notion-create-pages/notion-update-page调用都依赖 Notion MCP 服务器。SKILL.md 第 0 步专门处理了连接失败的情况添加 Notion MCPcodex mcp add notion --url https://mcp.notion.com/mcp启用远程 MCP 客户端在config.toml中设置[features].rmcp_client true或运行codex --enable rmcp_client使用 OAuth 登录codex mcp login notion登录成功后需重启 codex 才能生效。这一步对数据库迁移这类多轮、长周期的任务尤为关键——迁移跨越建表、回填、双写、切读、下线多个阶段期间每次会话都要依赖稳定的 Notion 连接来读写计划与任务。六、从案例到方法论迁移类任务的通用模板本案例虽然以用户偏好 Schema为例但其工作流可平移至任何数据迁移/重构场景。综合 database-migration.md 与 SKILL 参考文件可沉淀为如下可复用的执行清单解析阶段用notion-search定位 Specnotion-fetch拉全文按 spec-parsing.md 抽取功能需求、非功能需求性能/可用性/合规、约束、验收标准、优先级对含糊或缺失信息先记录 Clarifications/Missing Information 区块再继续推进。计划阶段多阶段迁移 → standard-implementation-plan.md简单变更 → quick-implementation-plan.md阶段划分遵循建基座 → 数据迁移 → 双写/切换 → 清理/收尾顺序每一阶段写明 Goal、Tasks、Deliverables、Estimated effort并建立严格的依赖链。任务阶段任务粒度控制在 12 天单一直达交付物独立可测使用 task-creation-template.md 撰写 Context / Objective / Acceptance Criteria / Technical Approach / Dependencies用data_source_id定位任务集合属性名以任务数据库实际 Schema 为准为任务设置 Status、Priority、Sprint/Story Points、关系属性关联 Spec 与 Plan。执行阶段按 progress-tracking.md 的节奏更新状态任务流转、阶段勾选、时间线修订、阻断项记录阶段收尾用 milestone-summary-template.md 输出里程碑总结含 Metrics、Challenges、Learnings、Impact on Timeline保持 Plan 页面为唯一事实源source of truth。七、验证与评估如何确认技能真正生效仓库在 evaluations/README.md 中提供了两个可复跑的评估场景用于验证技能在不同 Codex 模型Haiku / Sonnet / Opus上的稳定性basic-spec-implementation.json验证Spec → 实施计划的基础工作流搜索 Spec、解析需求、分阶段建计划、链接回原文spec-to-tasks.json验证Spec → 任务数据库的任务创建提取需求与验收标准、确认任务库 Schema、批量创建带属性与依赖的任务并回链 Spec。其中对数据库迁移类场景尤为相关的验收口径包括任务标题具体可执行如 Create login API endpoint 而非 Authentication、验收标准为- [ ]清单、任务通过 mention-page 回链 Spec。你可以按 README 中的步骤——启用技能 → 提交评估文件中的查询 → 核对计划与任务产出——来端到端检验本案例所述流程在自己环境中的实际效果。八、小结数据库迁移是工程风险最高的改动类型之一而notion-spec-to-implementation技能把这份风险转化为可控的阶段、可验收的任务、可追溯的链接Spec 是唯一需求来源Plan 是执行蓝图Tasks 是 12 天粒度的落地单元Progress 是持续同步的进度仪表盘。从 database-migration.md 这个案例出发再对照 api-feature.mdAPI 功能开发与 ui-component.mdUI 组件实现两个姊妹案例可以看到无论交付物是表结构、REST 接口还是前端组件定位 Spec → 解析需求 → 分阶段计划 → 批量建任务 → 持续跟踪这套闭环都同样成立——这正是该技能在 awesome-codex-skills 生态中的核心价值。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 notion-spec-to-implementation 技能规划并落地数据库迁移：以用户偏好 Schema 重构为例
用 notion-spec-to-implementation 技能规划并落地数据库迁移以用户偏好 Schema 重构为例【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills本文是 awesome-codex-skills 仓库中notion-spec-to-implementation技能的完整案例解析。它围绕 examples/database-migration.md 中的用户偏好 Schema 数据库迁移实战演示了如何把一份 Notion 中的技术规格Spec自动转换为可执行的实施计划、任务看板与进度追踪体系适用于 PRD、技术设计文档、迁移/重构类工单的端到端落地。读完本文你将掌握如何用Notion:notion-search/notion-fetch定位并解析 Spec如何按分阶段 双向依赖原则生成实施计划如何把计划拆解为符合验收标准的任务并写入 Notion 任务数据库以及如何在执行阶段持续同步状态、阻断项与里程碑结论。一、技能定位从 Spec 到实现的全链路编排在 SKILL.md 中notion-spec-to-implementation被定义为Turn Notion specs into implementation plans, tasks, and progress tracking; use when implementing PRDs/feature specs and creating Notion plans tasks from them.它的核心价值是把一份躺在 Notion 里的规格文档变成可执行、可追踪、可验收的工程资产产物包括三样东西实施计划页Implementation Plan链接回原始 Spec包含需求摘要、技术方案、分阶段实施步骤、依赖/风险、成功标准任务数据库中的任务Tasks以 12 天为粒度的可执行任务带上下文、验收清单、依赖关系并双向关联 Spec 与 Plan持续的状态更新Progress Tracking随实施进度同步状态字段、里程碑总结与阻断项。SKILL.md 给出的 Quick Start 五步法也是后面数据库迁移案例的骨架1) 用 Notion:notion-search 定位 Spec再用 Notion:notion-fetch 拉取全文 2) 用 reference/spec-parsing.md 解析需求与歧义点 3) 用 Notion:notion-create-pages 创建计划页在 quick 与 standard 两种模板中选择 4) 找到任务数据库、确认 schema再用 Notion:notion-create-pages 创建任务 5) 用 Notion:notion-update-page 维护 Spec ↔ Plan ↔ Task 之间的链接与状态仓库还提供了两类辅助资产reference/目录存放解析模式、计划/任务模板与进度节奏如 spec-parsing.md、standard-implementation-plan.md、task-creation.md、progress-tracking.mdexamples/目录则给出三种典型场景的端到端走读ui-component.md、api-feature.md、database-migration.md。本文的主角就是其中风险最高、也最能体现分阶段实施价值的数据库迁移案例。二、案例背景与初始用户请求数据库迁移案例的初始用户请求是Plan and implement the database migration for user preferences schema这是一个典型的迁移 重构类任务存量系统已运行、数据不能丢、服务不能停。原文将其拆解为以下核心约束现状Current用户偏好以JSONB单列preferences存储目标Target拆分为user_preferences与notification_preferences两张结构化表硬性要求Must maintain迁移期间保持向后兼容性能指标Performance支撑 100 万以上用户、零停机迁移。从 spec-parsing.md 的分类法看这段描述同时包含了功能需求表结构拆分、非功能需求零停机、规模上限与约束条件向后兼容为后续的分阶段计划提供了全部输入。三、完整工作流走读五步把迁移落地到 Notion3.1 第 1 步查找并获取 Spec迁移工程的第一步是找到那份规格而不是凭经验直接开写 SQL。原文给出的调用序列Notion:notion-search → Found User Preferences Schema Migration Spec Notion:notion-fetch → Extracted requirements对应的 Spec 摘要为Migrate from JSON blob to structured schema for better performance and data integrity.从 JSON 大字段迁移到结构化 Schema以换取更优的性能与数据完整性。spec-parsing.md 补充了搜索阶段的容错策略若返回多个结果应询问用户选择哪一个若未找到则应向用户索要页面 URL/ID。这是保证以真实 Spec 为准、不臆造需求的关键一步。3.2 第 2 步解析需求抓取到 Spec 全文后原文把需求提炼为四要素CurrentJSONB preferences列Target独立的user_preferences与notification_preferences两张表Must maintain迁移过程中的向后兼容Performance支持 100 万 用户、零停机。这四项正是后续所有任务验收标准的来源。例如向后兼容会演化为Phase 3 双写模式的验收条件零停机则要求Phase 4 切换读路径时新旧并存、可快速回滚。3.3 第 3 步创建实施计划计划页通过Notion:notion-create-pages写入 Notion原文给出的最小调用Notion:notion-create-pages pages: [{ properties: { title: Implementation Plan: User Preferences Migration }, content: [Full implementation plan with phases] }]迁移计划的精髓在于五阶段推进每一阶段都对应一条独立的工程目标阶段目标关键动作Phase 1建表创建新表并建立索引Phase 2回填从 JSONB 回填存量数据Phase 3双写新旧两套写入并存dual-writePhase 4切读读路径切换到新 SchemaPhase 5下线删除旧 JSONB 列这与 standard-implementation-plan.md 中Overview → Linked Specification → Requirements Summary → Technical Approach → Implementation Phases → Dependencies → Risks Mitigation → Timeline → Success Criteria的模板骨架一脉相承——迁移类工程天然适合先基础、再核心、后收尾的 phased 编排。同时 SKILL.md 也明确指出简单变更用quick-implementation-plan.md多阶段特性/迁移则用standard-implementation-plan.md本案例属于后者。3.4 第 4 步查找任务数据库并创建任务这是从计划到执行的落地点。原文的调用分两小步先定位任务数据库并确认 SchemaNotion:notion-search → Found Engineering Tasks database Notion:notion-fetch → Got schema (Task, Status, Priority, Assignee, etc.)再批量写入任务以data_source_id指向任务集合Notion:notion-create-pages parent: { data_source_id: collection://xyz } pages: [ { properties: { Task: Write migration SQL scripts, Status: To Do, Priority: High, Sprint: Sprint 25 }, content: ## Context\nPart of User Preferences Migration...\n\n## Acceptance Criteria\n- [ ] Migration script creates tables\n- [ ] Indexes defined... }, // ... 4 more tasks ]task-creation.md 详细说明了这一步的规范先搜索任务数据库query: Engineering Tasks再 fetch 数据库 schemacollection://...形式的 data source确认属性名与类型后按parent: { type: data_source_id, data_source_id: collection://tasks-db-uuid }创建页面同时给出了属性设置的约定例如properties: { [Title Property]: Task: [Clear task name], Status: To Do, Priority: [High/Medium/Low], [Project/Related]: [spec-page-id, plan-page-id], Assignee: [Person] (if known), date:Due Date:start: [Date] (if applicable), date:Due Date:is_datetime: 0 }原文为本次迁移生成了5 个任务Write migration SQL scripts编写迁移 SQL 脚本Implement backfill job实现回填任务Add dual-write logic to API在 API 中加入双写逻辑Update read queries更新读查询Rollback plan monitoring回滚计划与监控注意这 5 个任务与五阶段计划的对应关系任务 1 对应 Phase 1 建表任务 2 对应 Phase 2 回填任务 34 对应 Phase 3 双写与 Phase 4 切读任务 5 贯穿全程的可靠性保障。任务标题遵循 task-creation.md 的命名规范——使用动作动词Write / Implement / Add / Update / Rollback具体而非含糊✓ Write migration SQL scripts✗ Add login 这类反例。task-creation-template.md 给出了每个任务正文的推荐结构Context关联 Spec 与 Plan、Description、Acceptance Criteria- [ ]清单、Technical Details、Dependencies、Resources、Progress。3.5 第 5 步跟踪进度任务创建完成后进入持续执行与同步阶段。原文描述为Regular updates to implementation plan with status, blockers, and completion notes.以状态、阻断项与完成备注定期更新实施计划。progress-tracking.md 给出了更细的节奏约定每日更新任务状态变更、进度备注、阻断项、里程碑更新阶段完成、时间线调整、干系人汇报、状态流转更新To Do → In Progress → In Review → Done / Blocked。阶段完成时使用 milestone-summary-template.md日常同步则采用 progress-update-template.md 的六段式Completed Today / In Progress / Next Steps / Blockers / Notes。对迁移类项目进度页还应维护当前阶段 回滚就绪状态这正是任务 5回滚计划与监控持续输出的内容。四、关键产出与成功要素4.1 关键产出Key Outputs原文把本次会话的产物归纳为三件Implementation Plan Page实施计划页已链接回原始 Spec5 Tasks in Database任务数据库中的 5 个任务含依赖关系与验收标准Progress Tracking随工作推进持续更新的进度记录。三者构成Spec → Plan → Tasks → Progress的完整闭环与 SKILL.md 中Link artifacts的要求一致Plan 链接 SpecTasks 同时链接 Plan 与 Spec可选地用Notion:notion-update-page在 Spec 末尾追加Implementation小节回指计划与任务形成双向导航。这一模式在 api-feature.md 中体现得更细——它展示了用command: insert_content_after在 Spec 的 Acceptance Criteria 之后插入 Implementation 摘要的完整调用。4.2 成功要素Success Factors原文提炼了 5 条经验它们是迁移类任务可复用的方法论将复杂迁移拆解为清晰阶段Broke down complex migration into clear phases为任务定义具体的验收标准Created tasks with specific acceptance criteria建立阶段间依赖Established dependenciesPhase 1 → 2 → 3 → 4 → 5零停机方案并配套回滚计划Zero-downtime approach with rollback plan所有工作均回链原始 SpecLinked all work back to original spec。其中第 3 点直接对应 task-creation.md 的依赖链模式Dependency Chain PatternTask A 建表 → 阻塞 Task B 回填 → 阻塞 Task C 双写 → 阻塞 Task D 切读第 2 点对应其验收标准必须可测试的要求✓ Page loads in 2 seconds✗ System is fast第 5 点则与 evaluations/README.md 中Tasks link back to spec using mention-page tag的验收口径完全吻合。五、环境准备Notion MCP 连接上述所有Notion:notion-search/notion-fetch/notion-create-pages/notion-update-page调用都依赖 Notion MCP 服务器。SKILL.md 第 0 步专门处理了连接失败的情况添加 Notion MCPcodex mcp add notion --url https://mcp.notion.com/mcp启用远程 MCP 客户端在config.toml中设置[features].rmcp_client true或运行codex --enable rmcp_client使用 OAuth 登录codex mcp login notion登录成功后需重启 codex 才能生效。这一步对数据库迁移这类多轮、长周期的任务尤为关键——迁移跨越建表、回填、双写、切读、下线多个阶段期间每次会话都要依赖稳定的 Notion 连接来读写计划与任务。六、从案例到方法论迁移类任务的通用模板本案例虽然以用户偏好 Schema为例但其工作流可平移至任何数据迁移/重构场景。综合 database-migration.md 与 SKILL 参考文件可沉淀为如下可复用的执行清单解析阶段用notion-search定位 Specnotion-fetch拉全文按 spec-parsing.md 抽取功能需求、非功能需求性能/可用性/合规、约束、验收标准、优先级对含糊或缺失信息先记录 Clarifications/Missing Information 区块再继续推进。计划阶段多阶段迁移 → standard-implementation-plan.md简单变更 → quick-implementation-plan.md阶段划分遵循建基座 → 数据迁移 → 双写/切换 → 清理/收尾顺序每一阶段写明 Goal、Tasks、Deliverables、Estimated effort并建立严格的依赖链。任务阶段任务粒度控制在 12 天单一直达交付物独立可测使用 task-creation-template.md 撰写 Context / Objective / Acceptance Criteria / Technical Approach / Dependencies用data_source_id定位任务集合属性名以任务数据库实际 Schema 为准为任务设置 Status、Priority、Sprint/Story Points、关系属性关联 Spec 与 Plan。执行阶段按 progress-tracking.md 的节奏更新状态任务流转、阶段勾选、时间线修订、阻断项记录阶段收尾用 milestone-summary-template.md 输出里程碑总结含 Metrics、Challenges、Learnings、Impact on Timeline保持 Plan 页面为唯一事实源source of truth。七、验证与评估如何确认技能真正生效仓库在 evaluations/README.md 中提供了两个可复跑的评估场景用于验证技能在不同 Codex 模型Haiku / Sonnet / Opus上的稳定性basic-spec-implementation.json验证Spec → 实施计划的基础工作流搜索 Spec、解析需求、分阶段建计划、链接回原文spec-to-tasks.json验证Spec → 任务数据库的任务创建提取需求与验收标准、确认任务库 Schema、批量创建带属性与依赖的任务并回链 Spec。其中对数据库迁移类场景尤为相关的验收口径包括任务标题具体可执行如 Create login API endpoint 而非 Authentication、验收标准为- [ ]清单、任务通过 mention-page 回链 Spec。你可以按 README 中的步骤——启用技能 → 提交评估文件中的查询 → 核对计划与任务产出——来端到端检验本案例所述流程在自己环境中的实际效果。八、小结数据库迁移是工程风险最高的改动类型之一而notion-spec-to-implementation技能把这份风险转化为可控的阶段、可验收的任务、可追溯的链接Spec 是唯一需求来源Plan 是执行蓝图Tasks 是 12 天粒度的落地单元Progress 是持续同步的进度仪表盘。从 database-migration.md 这个案例出发再对照 api-feature.mdAPI 功能开发与 ui-component.mdUI 组件实现两个姊妹案例可以看到无论交付物是表结构、REST 接口还是前端组件定位 Spec → 解析需求 → 分阶段计划 → 批量建任务 → 持续跟踪这套闭环都同样成立——这正是该技能在 awesome-codex-skills 生态中的核心价值。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考