用途：进入探索模式，作为思考伙伴与用户一起梳理想法、调查问题、澄清需求。此模式定位于思考而非实现，可读取文件、检索代码、调查代码库，但不得编写代码或实现功能；若用户要求实现，应提示先退出探索模式并创建变更提案。用户主动要求时，可创建 OpenSpec 制品（提案、设计、规格）以承载思考，但不应自动捕获或施加压力。
主要能力：以好奇而非规定性的方式提问；开放多条线索而非单一路径；使用 ASCII 图辅助理清思路；结合真实代码库而非空想；探索问题空间、挑战假设、重构问题、寻找类比；绘制现有架构、寻找集成点与既有模式、暴露隐藏复杂度；比较方案、构建对比表、草拟取舍；识别风险与未知、发现理解缺口、建议验证性调查。
使用方式：开始时运行 openspec list --json 查看是否存在活跃变更及其名称、schema 与状态，并从返回的 root.path 读取 openspec/config.yaml 或 config.yml 中的 context（项目背景、技术栈、约定、约束）与 rules（按制品 id 索引，仅在写入该制品时适用），将其作为约束而非可直接复制的内容。若用户指定 store（本机注册的独立 OpenSpec 仓库），先运行 openspec store list --json 发现已注册 store id，再在读写规格与变更的命令（new change、status、instructions、list、show、validate、archive、doctor、context、view）上附加 --store <id>，选定后保持粘性；未指定 store 时命令作用于最近的本地 openspec/ 根目录。
无变更时：自由思考，待洞察成熟后询问是否创建变更提案。若用户要求把探索捕获为新变更，先运行 openspec new change "<name>"（适用时带 --store <id>）进行脚手架初始化，切勿手工创建 openspec/changes/ 下的变更目录（CLI 会生成 .openspec.yaml 等必需元数据）。随后运行 openspec status --change "<name>" --json，按依赖顺序处理所需制品；对就绪的制品运行 openspec instructions "<artifact-id>" --change "<name>" --json，按返回模板与指令写入 resolvedOutputPath，并读取 dependencies 中的已完成依赖文件。若指令带有条件，需对照所探索的变更评估，条件不适用时记录为有意跳过；若所需制品被用户未请求的直接前置制品阻塞，先对前置制品运行 instructions：其指令若含条件，评估后仅在条件不适用时记录跳过，条件适用或本无条件则视为正常前置并先询问用户是否扩大捕获范围，未经同意不创建未被请求的前置制品。每创建一个制品后重跑 status，直至全部完成、跳过或有条件跳过。依赖是促成而非门禁：若某制品仅因有意跳过的条件前置而仍处于阻塞，可无视阻塞状态运行其 instructions，并在这些记录的条件跳过是其唯一缺失依赖时进行创建（按第 3 步）。若被用户未要求且无法条件跳过的前置阻塞，应解释依赖并先询问。用户仅要求启动变更时，脚手架完成后停止并展示状态。
已存在变更时：运行 openspec status --change "<name>" --json，使用 changeRoot、artifactPaths 与 actionContext，从 artifactPaths.<artifact>.existingOutputPaths 读取既有文件并在对话中自然引用。当决策形成时可提议捕获：新需求或需求变更写入 specs/<capability-path>/spec.md（capability-path 为相对 specs/ 的规格目录，如 user-auth 或 identity/user-auth，需保留既有能力的完整路径并遵循项目对新能力的组织惯例）；设计决策写入 design.md；范围变化写入 proposal.md；新工作写入 tasks.md；假设失效写入相关制品。由用户决定，只提议不自动捕获。
适用场景：用户带来模糊想法、具体问题、实现中途卡住，或想比较方案时使用。可画状态机、数据流、架构草图、依赖图与对比表。
限制：只思考不实现，不写应用代码；不清楚就深挖而不假装理解；不急于下结论；不强制结构与固定流程；不自动捕获；不手工创建变更目录；无必需产出或固定终点。
支持的触发方式：Codex 中为 $openspec-explore，其他 agent 中为 /openspec-explore，可接变更名参数。具体价格、平台要求、安装步骤等暂未提供。