用途：进入“探索模式”，作为思考伙伴帮助用户梳理想法、调查问题、澄清需求。它强调这是一种立场而非固定工作流，没有强制步骤或输出。
主要能力：提出澄清性问题、挑战假设、重新界定问题、寻找类比；调研代码库、梳理现有架构、定位集成点与既有模式、暴露隐藏复杂度；比较多种方案、制作对比表、权衡取舍；用 ASCII 图可视化系统结构、状态机、数据流、依赖图；识别风险与未知、发现理解缺口、建议调研或 spike。
使用方式：开始时可用 openspec list --json 查看是否存在活跃变更及其名称、schema 与状态，并读取项目根目录下 openspec/config.yaml（或 config.yml）中的 context 与 rules 作为约束（不要复制到对话或产物中）。若用户指定了已注册的独立 store，先运行 openspec store list --json 获取 id，再在读取或写入规格与变更的命令上追加 --store <id>（如 new change、status、instructions、list、show、validate、archive、doctor、context、view），选定后保持粘性；其他命令不接受该标志。无 store 时命令作用于最近的本地 openspec/ 根。
捕获探索结果：若用户要求把探索固化为新变更，先运行 openspec new change "<name>"（适用时带 --store <id>）进行脚手架，不要手工创建 openspec/changes/ 下的目录；随后运行 openspec status --change "<name>" --json，按依赖顺序对就绪产物运行 openspec instructions "<artifact-id>" --change "<name>" --json，按返回模板与说明写入 resolvedOutputPath，并核对输出存在。若某产物被未请求的前置依赖阻塞，需先询问再扩展捕获；条件不适用时可记录为有意跳过。
限制：绝不写代码或实现功能；用户要求实现时应提醒其退出探索模式并创建变更提案。可以创建 OpenSpec 产物（提案、设计、规格），但那是记录思考而非实现。不要伪造理解、不要急于下结论、不要强制结构、不要自动捕获（应提议而非直接保存）、不要手工搭建变更目录。
适用场景：想法尚模糊时发散探索、遇到具体问题时调研代码库、实现中途卡住时重新梳理、需要比较技术选型时。资料未提供收费、价格、平台与效果等信息。