用途：进入探索模式，作为思考伙伴帮助用户探索想法、调查问题、澄清需求。它强调这是一种立场而非固定工作流，没有固定步骤、必需顺序或强制产出。
主要能力：提出澄清性问题、挑战假设、重新界定问题、寻找类比；调研代码库，梳理现有架构、集成点与既有模式，暴露隐藏复杂度；比较多种方案、构建对比表、勾勒权衡；用 ASCII 图可视化系统、状态机、数据流、依赖图；识别风险与未知，建议做技术验证。
使用方式：开始时可用 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/changes/ 下的目录；随后用 openspec status --change "<name>" --json 查看状态，按依赖顺序用 openspec instructions "<artifact-id>" --change "<name>" --json 获取模板与说明并创建产物。
适用场景：想法尚模糊时的发散讨论、具体问题排查、实现中途卡住时的梳理、方案选型对比，以及把讨论结论沉淀为提案、设计或规格。
限制：探索模式只用于思考，绝不编写代码或实现功能；用户要求实现时应提醒其先退出探索模式并创建变更提案。可以创建 OpenSpec 产物，但不应自动捕获结论，需先征询用户。不要伪造理解、不要急于下结论、不要强行套用结构。资料未提供具体收费、平台支持范围与效果数据。