用途：进入探索模式，作为思考伙伴与用户一起探索想法、调查问题、澄清需求。核心定位是思考而非实现，可读文件、搜索代码、调研代码库，但不允许编写代码或实现功能；若用户要求实现，应提示先退出探索模式并创建变更提案。如用户要求，可以创建 OpenSpec 工件（提案、设计、规格），这属于记录思考而非实现。
主要能力：提出问题、挑战假设、重新表述问题、寻找类比；调研代码库、梳理现有架构与集成点、识别既有模式；比较方案、做取舍表、按需推荐路径；用 ASCII 图（系统图、状态机、数据流、依赖图、对比表）辅助表达；识别风险与未知、指出理解缺口、建议调研或 spike。
使用方式：属于一种姿态而非固定工作流，没有必选步骤和强制产出。开始时可用 openspec list --json 查看是否存在活跃变更及状态；再从解析出的根读取 openspec/config.yaml（或 config.yml，存在时）中的 context 与 rules 作为约束（不要复制到对话或工件中）。若指定 store（本机注册的独立 OpenSpec 仓库），先运行 openspec store list --json 发现注册的 id，再在读写规格与变更的命令上追加 --store <id>（新变更、status、instructions、list、show、validate、archive、doctor、context、view），且对该工作流保持粘性；其他命令不接受该参数；未指定 store 时命令作用于最近的本地 openspec/ 根。
当没有变更时，可自由思考，成熟时询问是否创建提案；若用户要求把探索沉淀为新变更，先运行 openspec new change "<name>" 脚手架，不要手工在 openspec/changes/ 下建目录，然后运行 openspec status --change "<name>" --json，按依赖顺序处理用户请求的工件，对每个就绪工件运行 openspec instructions "<artifact-id>" --change "<name>" --json，按模板与指令写入，写完后重新查看状态；如被未请求的前置项阻塞，需先说明依赖并获得用户同意再扩展。若存在变更，运行 openspec status --change "<name>" --json，使用其中的 changeRoot、artifactPaths、actionContext 读取现有工件并自然引用；按洞见类型提示记录位置：新需求或需求变更写入 specs/<capability-path>/spec.md，设计决策写入 design.md，范围变化写入 proposal.md，新工作写入 tasks.md。是否记录由用户决定，只做建议，不自动沉淀。
入口示例包括：用户提出模糊想法（如实时协作）、具体问题（如认证系统混乱）、实现中途卡住、想比较方案（如 Postgres 与 SQLite）。结果可以流入提案、更新工件、仅获得清晰认识或稍后继续，总结为可选。
限制：禁止实现功能或编写应用代码；不清楚就不要假装理解；不急于下结论；不强迫结构；不自动记录洞见；手工脚手架变更被禁止，必须用 openspec new change "<name>"（适用时带 --store <id>）以生成 .openspec.yaml 等必需元数据。