用途：进入探索模式，作为思考伙伴帮助用户梳理想法、调查问题、澄清需求。它强调这是一种立场而非固定工作流，没有固定步骤、必需顺序或强制产出。
主要能力：提出澄清性问题、挑战假设、重新界定问题、寻找类比；调查代码库、梳理现有架构、定位集成点、识别既有模式、暴露隐藏复杂度；比较方案、头脑风暴、绘制对比表、权衡取舍；用 ASCII 图可视化系统、状态机、数据流、架构草图与依赖图；识别风险与未知、发现理解缺口、建议调研或 spike。
使用方式：开始时可用 openspec list --json 查看是否存在活跃变更及其名称、schema 与状态，并读取项目根目录下的 openspec/config.yaml（或 config.yml）中的 context 与 rules 作为约束。若用户指定了 store，可运行 openspec store list --json 获取已注册 store id，并在读取或写入规格与变更的命令上追加 --store <id>，选定后保持粘性。若用户要求把探索固化为新变更，先运行 openspec new change "<name>" 脚手架，再运行 openspec status --change "<name>" --json，并按依赖顺序对就绪产物运行 openspec instructions "<artifact-id>" --change "<name>" --json，按返回模板写入 resolvedOutputPath。已有变更时，用 status 返回的 changeRoot、artifactPaths、actionContext 读取现有产物，并自然引用。
适用场景：用户带来模糊想法、具体问题、实现中途卡住，或需要比较技术选项时。
限制：探索模式只用于思考，绝不编写代码或实现功能；用户要求实现时应提醒其先退出探索模式并创建变更提案。可以创建 OpenSpec 产物（提案、设计、规格），但不得手工在 openspec/changes/ 下创建变更目录，必须使用 CLI 脚手架以生成 .openspec.yaml 等元数据。不要自动捕获洞察，应主动提议由用户决定。不要伪造理解、不要急于下结论、不要强行套用结构。资料未提供具体收费、价格与平台支持信息。