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