用途
openspec-explore 是 getsentry/toolkit 提供的技能，用于进入“探索模式”（explore mode）。它的定位是思考伙伴，而不是执行者，面向需要想清楚问题、而不是马上写代码的场景：探索想法、调查问题、澄清需求。
资料强调：探索模式用于思考，不用于实现。可以阅读文件、搜索代码、调查代码库，但绝不能编写代码或实现功能。如果用户要求实现某项功能，应提醒用户先退出探索模式，再创建变更提案。若用户提出要求，可以创建 OpenSpec 工件（提案、设计、规格），这属于记录思考，不属于实现。
主要能力
资料将其描述为一种“姿态”而非工作流：没有固定步骤、没有必需顺序、没有强制输出。具体可能的行为包括：
- 探索问题空间：提出澄清性问题、挑战假设、重新界定问题、寻找类比。
- 调查代码库：梳理与讨论相关的现有架构、寻找集成点、识别已在使用的模式、揭示隐藏的复杂度。
- 比较选项：发散多种方案、制作对比表、勾勒权衡、在被要求时推荐路径。
- 可视化：大量使用 ASCII 图辅助思考，如系统图、状态机、数据流、架构草图、依赖图、对比表。
- 暴露风险与未知：识别可能出错之处、找出理解上的空白、建议 spike 或调查。
使用方式
该技能没有固定的操作流程，行为随用户带来内容的不同而变化，资料给出了几种入口示例：
- 用户带来模糊想法（如“想加实时协作”）：用协作光谱图（感知／协调／同步）帮助定位。
- 用户带来具体问题（如“认证系统很乱”）：阅读代码库并画出现有认证流程图，指出可切入的纠缠点。
- 用户实现中途卡住（示例命令
/opsx:explore add-auth-system）：读取变更工件，追踪涉及内容，画图、探索选项、建议路径，并询问是否更新设计或增加 spike 任务。 - 用户想比较选项（如 Postgres 与 SQLite）：先问上下文，再基于约束制作对比表。
OpenSpec 感知方面：开始时快速执行 openspec list --json 检查是否存在活动变更及其名称、schema 和状态。没有变更时可以自由思考，洞察成形后可提议创建提案。存在变更时，运行 openspec status --change "<name>" --json，使用返回的 changeRoot、artifactPaths、actionContext，从 artifactPaths.<artifact>.existingOutputPaths 读取现有文件，并在对话中自然引用。
当讨论产生决策时，可以提议记录，但不自动记录、不施压，由用户决定：
- 发现新需求 → specs/<capability>/spec.md
- 需求变更 → specs/<capability>/spec.md
- 设计决策 → design.md
- 范围变更 → proposal.md
- 识别新工作 → tasks.md
- 假设失效 → 相关工件
适用场景
适合需要深入思考而非产出的时段：需求尚不清晰、方案存在多条路径、需要理解现有代码结构、实现前想先评估风险与未知、想比较技术选型。资料明确说明不必遵循脚本、不必每次问同样的问题、不必产出特定工件、不必得出结论，有价值的跑题也可以继续。
限制
- 绝不写代码或实现功能；创建 OpenSpec 工件可以，写应用代码不行。
- 创建工件需要用户提出或同意，不自动捕获洞察。
- 不伪造理解，不清楚就深挖；不急于下结论。
- 结束方式不固定：可能流入提案、更新工件、仅提供清晰思路或留待以后继续；结尾总结是可选的。
- 资料未提供安装命令、收费、平台支持等细节，暂未提供。