新建任务，选择项目目录
在 Codex 桌面端新建任务，把工作目录设为：
~/Projects/reading-list现在该说哪一句？
可直接复制$openspec-propose 为阅读清单增加批量导入需求已经大致明确，希望把想法变成可讨论、可执行的 Change。
先把 Codex 放进正确的项目。
这是唯一必须先做对的动作。项目不对，OpenSpec Skill 就不会出现。
提出变更
$openspec-propose把明确的需求变成方案与任务。
还没想清楚
$openspec-explore只研究，不动代码。
按任务实现
$openspec-apply-change方案确认后再开工。
同步并收口
$openspec-sync-specs$openspec-archive-change让规范和最终代码保持一致。
$openspec-propose →$openspec-explore →$openspec-apply-change →$openspec-sync-specs →$openspec-archive-change →$openspec-propose →$openspec-explore →$openspec-apply-change →$openspec-sync-specs →$openspec-archive-change →
五个 Skill，刚好是一条完整路线。
你不需要复制 .claude/commands/opsx/，也不用切到 Claude Code。Codex 直接调用项目里的 Skill。
判断原则还在想，用 explore。准备成文，用 propose。方案确认，才 apply。
提出变更
$openspec-propose需求已经大致明确，希望把想法变成可讨论、可执行的 Change。
生成 proposal、design 与 tasks，先把边界说清楚。先想明白
$openspec-explore问题还模糊，需要阅读现状、梳理约束，暂时不改代码。
得到现状分析、风险和下一步建议，不进入实现。开始实现
$openspec-apply-changeChange 已经评审清楚，tasks 也准备好了。
Codex 按 tasks 实现、测试，并持续更新完成状态。同步规范
$openspec-sync-specs实现改变了长期行为，需要让主 specs 反映最终事实。
把 Change 中确认过的差异同步回主规范。完成归档
$openspec-archive-change代码、测试和规范都已完成，需要正式收口。
检查遗漏并归档 Change，留下可追溯记录。点开一个动作，看看该怎么说。
每一句都可以原样发给 Codex，再按你的真实需求改名。
$openspec-propose 为阅读清单增加批量导入生成 proposal、design 与 tasks，先把边界说清楚。
真正难的不是语法，是判断现在处在哪一步。
用三个常见场景练一遍，你就会选了。
我只有一个模糊想法
你知道要改善导入流程，但还不确定格式、数据结构和影响范围。
应该用
$openspec-explore先研究，不要求 Codex 写代码。
需求已经能说清楚
目标、用户和主要限制都明确，希望形成正式方案供评审。
应该用
$openspec-propose让 Codex 先产出 Change，再决定是否实现。
方案通过，准备开工
proposal、design 和 tasks 已经确认，可以按任务清单推进。
应该用
$openspec-apply-change实现结束后再同步 specs，并完成归档。
01 / 03
你知道要改善导入流程，但还不确定格式、数据结构和影响范围。
$openspec-explore 研究批量导入会影响哪些格式、页面和数据现在，从一个真实 Change 开始。
打开你的项目，新建 Codex 任务，然后发出第一句。
$openspec-propose 为阅读清单增加批量导入