explore 是一个面向“学习与评估”场景的技能，用于回答技术问题，而不把问题变成一次交付项目。它的前提是：用户正在学习、比较方案或评估影响，尚未承诺要构建任何东西。提问或写输出文件时，它要求使用 ASD-STE100 简化技术英语。
【工作流程】 首先确立问题：复述问题及所需深度，不把它扩大成产品发现。 其次收集证据：对涉及仓库影响的问题，检查相关实现、调用方、测试、公开契约和近期变更；对外部技术，优先使用当前权威文档，并区分已记录行为与推断；对设计问题，以给定请求为框架，若用户提供意图工件，则用其中的 Problem、Constraints、Affected components 作为证据，并在起草候选方案前检查从触发到结果路径上的组件。重要论断按需标注为已确认（confirmed）、推断（inferred）或未知（unknown）。 当建议依赖当前外部信息时，需记录调研日期，找出最新的相关可行选项，不停留在第一个看似合理的选项；规范、版本、定价和已记录限制优先采用一手来源；每条可外部验证的事实性论断都给出引用，并区分实测证据、厂商声明、推断与未知；比较时使用对等的版本、配置、负载、定价单位和测量条件，解释实质性差异；在相关且可得时比较基准、定价、延迟和限制，无对等数据时明确说明；对重要的性能或可靠性论断，至少用一项独立基准或真实评估交叉核对，无独立证据时明确说明。
【模式】 仅推断请求所需的模式：
- Concept（概念）：说明某事物如何运作、在何处有用。
- Impact（影响）：检查当前仓库，识别采纳该变更会影响什么。
- Comparison（比较）：比较现实可行的选项及其取舍。
- Example（示例）：给出最小可用的代码示例。
- Design（设计）：为给定请求展示一个或多个高层候选设计，仅在用户要求设计或设计方案时使用。 一个请求可以组合多种模式。只有当所请求的结果可能明显改变调查方向时，才提一个澄清问题。
【输出方式】 默认在对话中回答。当用户要求可复用工件时，填写 assets/technical-brief-template.md 并保存到 docs/agentic-engineering/explorations/<YYYY-MM-DD>/<subject>.md；覆盖已有工件前先询问，用户批准后才标记为已验证。Design 模式下还写一个配套页面 docs/agentic-engineering/explorations/<YYYY-MM-DD>/<subject>-designs.html，并排呈现每个候选方案，每个候选一节，含名称、关键决策和图表；只用内联 CSS，唯一脚本是从 CDN 加载的 Mermaid 渲染器；该页面是简报的支持文件，不是带状态信息的工件；在对话中展示 Mermaid 代码块。不适用的可选章节应删除。
【边界与限制】 不创建规格说明或实现计划；不修改生产代码、项目配置、依赖或测试；当单一事实性回答已足够时不强行给出多选项（Design 模式除外，因为用户要求了候选方案）；不为用户选定设计候选，而是带理由推荐，由用户决定并可要求更多候选；未经验证不把示意性代码说成与仓库兼容或已测试；除用户要求外不估算工作量，若要求则说明假设并用区间而非虚假精度；绝不运行 git commit、创建分支或推送变更；探索不能替代交付工作前必需的上下文阶段。
【完成检查】 完成前确认：回答的是用户实际问题；涉及仓库的论断在适用时引用具体文件或符号；时效性重要时外部论断使用当前权威证据；当前建议说明调研日期并覆盖最新的相关可行选项；可外部验证的事实性论断有引用；清晰区分厂商声明、独立测量、推断与未知；实质性比较使用对等条件或解释为何不可直接比较；重要性能或可靠性论断经过独立交叉核对或说明缺乏独立证据；示例说明是否实际运行；任意两个设计候选在至少一个关键决策上不同，各自引用组件并说明约束契合度；下一步是可选而非默认承诺构建。