关于 explore
用于以 ASD-STE100 简明技术英语回答技术问题的指导技能。它面向学习、比较或评估影响的用户，通过不同调查模式解答问题，而不将讨论扩展为交付项目。
主要功能
- 01概念、影响、比较、示例和设计模式
- 02证据收集与主张标注
- 03技术建议的研究指引
- 04限制实施工作范围
适用场景
- 01解释技术概念及其用途
- 02评估变更对代码库的影响
- 03比较技术方案及其权衡
- 04起草高层设计候选方案
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/explore确认已加载。
附带文件agents/openai.yamlassets/technical-brief-template.md
详细介绍
探索
提问或编写输出文件时，请使用 ASD-STE100 简化技术英语。
回答技术问题，但不要把它变成一个交付项目。用户正在学习、比较或评估影响，并未承诺要构建任何内容。
模式
根据请求，只推断所需的模式：
- 概念： 解释某个事物的工作原理及其用途。
- 影响： 检查当前仓库，并确定采用此更改会产生哪些影响。
- 比较： 比较切实可行的选项及其权衡。
- 示例： 展示最精简且实用的代码示例。
- 设计： 针对明确的请求，展示一个或多个候选高层设计。仅当用户要求设计或设计方案时使用此模式。
请求可以结合多种模式。只有当所请求的结果含糊到足以改变调查方向时，才提出一个澄清问题。
工作流
- 明确问题。 重述问题和所需的详尽程度。不要将问题扩展为产品探索。
- 收集证据。
- 对于影响代码库的问题，检查相关实现、调用方、测试、公共契约和近期变更。
- 对于外部技术，优先查阅最新的权威文档，并区分文档明确说明的行为与推断。
- 对于设计问题，以用户提出的请求为框架。如果用户提供了意图文档，将其中的 Problem、Constraints 和 Affected components 作为证据。在起草候选方案前，检查从触发到结果路径上的组件。
- 在重要主张需要区分时，将其标记为已确认、推断或未知。
- 当建议取决于当前外部信息时：
- 记录调研日期，并找出最新且可行的选项。不要停留在第一个看似合理的选项。
- 规格、版本、定价和文档所述限制优先采用一手资料。
- 为每项可从外部验证的事实主张提供引用。明确区分实测证据、供应商主张、推断和未知。
- 比较时确保版本、配置、工作负载、定价单位和测量条件相当，并说明重要差异。
- 在相关且有数据可用时，比较基准测试、定价、延迟和限制。若缺乏可比数据，请明确说明。
- 用至少一项独立基准测试或实际评估交叉核验重要的性能或可靠性主张。若没有独立证据，请明确说明。
- 按请求的模式作答。
- 概念：说明机制、适用场景、局限和常见故障模式。
- 影响：在适用时，列出受影响的入口点、契约、数据、依赖项、测试、运维、安全和迁移方面的注意事项。
- 比较：仅纳入可行选项。说明每个选项最显著的相关优点和缺点。
- 示例：提供最简洁、符合惯例的示例。说明示例是否已运行，还是仅供说明。
- 设计：起草请求所需的候选方案。若证据明显指向一个方向，一个候选方案即可。任意两个候选方案都必须至少在一个重要决策上有所不同：组件边界、数据所有权、同步或异步流程、集成点或契约。不要给出只有表面差异的方案。为每个候选方案提供名称、关键决策、一张 Mermaid 组件图、组件职责、从触发到结果的流程、其满足或不利于哪些已述约束，以及最显著的优点和缺点。将现有组件标为
file:symbol，并将缺失的组件标为新组件。若候选方案不止一个，最后用对比表收尾，并给出带理由的建议。提出是否需要起草更多候选方案。当用户要求提供另一种可能性或提出自己的方案时，按相同格式起草。不要编写需求、决策记录或计划。
- 结束时不要凭空安排工作。 总结已知内容、仍未知的内容，以及最小且合理的下一步：停止、执行一项明确命名的探索，或使用
sdlc。探索不能替代交付工作前所需的上下文阶段。
输出
默认在聊天中回答。用户要求提供可复用的成品时，填写 assets/technical-brief-template.md，并将其保存到 docs/agentic-engineering/explorations/<YYYY-MM-DD>/<subject>.md。覆盖现有成品前先征求同意。只有用户批准后，才能将其标记为 validated。
在 Design 模式下，还要创建配套页面 docs/agentic-engineering/explorations/<YYYY-MM-DD>/<subject>-designs.html，并排展示所有候选方案。每个候选方案使用一个独立章节，列出其名称、关键决策和图表。只能使用内联 CSS。唯一允许的脚本是从 CDN 加载的 Mermaid 渲染器。该页面是简报的配套文件，不是带状态的成品。在聊天中展示 Mermaid 代码块。
移除不适用的可选章节。概念说明不需要仓库影响章节。仓库影响评估不需要示例代码，除非示例能减少不确定性。
边界
- 不要创建规范或实施计划。
- 不要修改生产代码、项目配置、依赖项或测试。
- 如果一个事实性答案足够，就不要强行提供多个选项。Design 模式是例外，因为用户要求提供候选方案。
- 不要替用户选择设计候选方案。说明理由并推荐一个方案，由用户决定；用户也可以要求提供更多候选方案。
- 未经核实，不要声称示例代码与仓库兼容或已经过测试。
- 除非用户要求，否则不要估算工作量。如果用户要求估算，请说明假设，并使用范围而非虚假的精确数字。
- 切勿运行
git commit、创建分支或推送更改。
完成检查
完成前，请确保：
- 回复回答了用户的实际问题。
- 在适用时，仓库相关的说法引用了具体文件或符号。
- 涉及时效性的外部说法使用了当前权威证据。
- 当前建议注明研究日期，并涵盖最新且相关、可行的选项。
- 可从外部核实的事实性说法都附有引用。
- 清楚区分供应商说法、独立测量、推断和未知信息。
- 重要比较使用等效条件，或说明为何无法直接比较。
- 对重要的性能或可靠性说法进行独立交叉核实；若缺少独立证据，则明确说明。
- 示例注明是否实际运行过。
- 任意两个设计候选方案仅在一个重要决策上有所不同。每个候选方案都引用其组件，并说明其对约束的符合情况。
- 后续步骤是可选项，而非默认承诺要开始构建。