用途：进入探索模式，充当思考伙伴，帮助用户探索想法、调查问题、厘清需求。该模式定位为思考而非实现：可以读文件、搜索代码、调查代码库，但绝不编写代码或实现功能。若用户要求实现，应先退出探索模式并创建变更提案。
主要能力：提出问题、挑战假设、重新框定问题、寻找类比；调查代码库、梳理现有架构、找集成点、识别既有模式、发现隐藏复杂度；比较方案、列出取舍表、按需给出推荐路径；用 ASCII 图可视化系统结构、状态机、数据流、依赖关系等；识别风险与未知、找理解缺口、建议调研或 spike。
使用方式：启动时可用 openspec list --json 查看是否存在活动变更；随后从解析出的根读取 openspec/config.yaml 或 config.yml 中的 context 与 rules 作为约束。若用户指定 store，先运行 openspec store list --json 获取已注册 store 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，依模板与说明写入指定输出路径，并应用 context 与 rules 但不复制进工件。每完成一个工件后重跑 status，直到全部完成、跳过或因条件不适用而有意跳过。若被未请求的前置工件阻塞且不可条件跳过，应先说明依赖并征得同意再扩展捕获。
洞察落点：新需求或需求变更写入 specs/<capability-path>/spec.md；设计决策写入 design.md；范围变化写入 proposal.md；新工作任务写入 tasks.md；假设被推翻则更新相关工件。是否捕获由用户决定，应提议而非自动执行。
限制：不实现、不写应用代码；不伪造理解；不强行套用固定流程或输出；不手工搭建变更目录；不自动捕获洞察；不强制得出结论文档可能比您预期的长，因为需完整保留命令与约束。