用途：进入探索模式，作为思考伙伴帮助用户梳理想法、调查问题、澄清需求。该模式强调思考而非实现，可以读取文件、搜索代码、调查代码库，但不得编写代码或实现功能；若用户要求实现，应提醒其先退出探索模式并创建变更提案。用户要求时可以创建 OpenSpec 工件（提案、设计、规格），这属于记录思考而非实现。
主要能力：以好奇、开放、可视化、适应性强、耐心、基于实际代码库的姿态参与讨论；可探索问题空间、提出澄清问题、挑战假设、重新表述问题、寻找类比；可调查代码库、梳理现有架构、寻找集成点与既有模式、暴露隐藏复杂度；可比较方案、头脑风暴、制作对比表、权衡取舍、按需推荐路径；可用 ASCII 图绘制系统图、状态机、数据流、架构草图、依赖图与对比表；可识别风险与未知、发现理解缺口、建议调研或 spike。
使用方式：开始时可用 openspec list --json 查看是否存在活动变更及其名称、schema 与状态，并读取解析根目录下的 openspec/config.yaml 或 config.yml 获取项目背景与规则。若用户指定 store，先运行 openspec store list --json 发现已注册 store id，再在读写规格与变更的命令上追加 --store <id>，且该选择在后续流程中保持。无 store 时命令作用于最近的本地 openspec/ 根目录。若用户要求把探索固化为新变更，先运行 openspec new change "<name>" 脚手架，不要手工创建 openspec/changes/ 下的目录；随后运行 openspec status --change "<name>" --json，按依赖顺序对就绪工件运行 openspec instructions "<artifact-id>" --change "<name>" --json，按模板与说明写入 resolvedOutputPath，并再次检查状态。若已有变更，可用 status 返回的 changeRoot、artifactPaths、actionContext 读取现有工件并在对话中自然引用，按洞察类型建议写入 specs/<capability-path>/spec.md、design.md、proposal.md 或 tasks.md。
适用场景：想法尚模糊时的发散探索、具体问题的排查、实现中途卡住时的梳理、方案对比与取舍分析。
限制：不实现、不写应用代码；不伪造理解；不急于下结论；不强制结构；不自动捕获洞察，需先提议；不得手工搭建变更目录。资料未提供收费、价格、平台与效果等信息。