使用技能
在用户调用 $use-skills 或请求明显需要结合多个已安装技能时使用此技能。
目的
选择一个小的、相关的技能工作集，并将它们的指导转化为一个连贯的结果。
合适的请求包括以下领域的组合：
规划和实施
审查和测试
写作和结构
设计和前端工作
文档和代码更改
当一个领域技能明显足够时，跳过此技能。
选择过程
使用下面的硬门来解决技能模式。
审查可见的技能列表。
将每个技能与用户请求和预期输出进行比较。
选择最强的匹配作为工作集。
仅当支持技能能够显著改善结果时，才使用它们。
仅读取选定技能中有助于当前任务的部分。
生成一个统一的答案、计划、补丁或建议。
保持工作集适合所选的模式。
推荐是用户想要平衡质量时的常用选择，但当没有可重用的先前选择时，应询问模式。
匹配标签
在选择时使用以下标签：
primary：直接塑造结果
support：添加有用的质量、结构、审查、措辞或边缘情况覆盖
skip：不适用于当前请求
如果没有技能是强匹配，则不使用此技能。
模式
在没有可重用的先前选择时，询问用户选择一个模式，模式应在任何工作空间探索、工具调用、文件读取、技能选择或主响应之前进行：
所有相关：使用所有与请求有意义相关的可用技能
推荐：使用请求的最佳平衡工作集
受限：仅使用最强的匹配，通常为一到三个技能
使用以下紧凑的终端友好格式，在围栏文本代码块内询问：
- 所有相关 - 使用所有与请求有意义相关的可用技能。
使用：use-skills，<所有相关技能候选项>
用于：<目的>的广泛覆盖
使用：use-skills，<推荐技能候选项>
用于：强大的输出而不产生不必要的噪音
使用：use-skills，<一到三个最强技能候选项>
用于：最小的技能参与和专注的输出
选择技能模式。
使用 1、2 或 3 回复。
模式选择硬门
如果 $use-skills 被调用且提示没有明确指定“所有相关”、“推荐”或“受限”，则下一个助手响应必须仅为：
上面的围栏文本模式菜单。
在询问之前，不要检查文件、搜索工作空间、读取技能文件或推断最终模式。
菜单应提及每个选项可能的技能。
仅使用当前提示和可见/提供的技能名称/描述来草拟这些候选列表。
在用户选择之前，不要使用工具来发现更多上下文。
允许在模式选择之前的候选来源：
当前会话中已安装的技能元数据
用户在当前对话中粘贴或提供的技能块，例如 enhance-prompt...
用户明确使用 $skill-name 命名的技能，当会话中存在可见/提供的描述时
将占位符技能候选项替换为实际可见/提供的技能名称，尽可能使用。
在模式菜单中，使用不带 $ 前缀的裸技能名称，例如 use-skills、brainstorming 和 writing-plans。
如果可见技能列表不可用，则说“模式选择后选择的技能”，而不是编造名称。
对于“所有相关”，要积极包含每个具有有意义的主要、支持、相邻上下文、提示质量、措辞、规划或框架角色的候选项。
如果技能通常有助于使提示、上下文、计划或输出更好，则即使它不是最窄的领域匹配，也应将其包含在“所有相关”中。
如果用户明确命名或提供技能，并且它具有任何合理的支持角色，则即使它过于广泛或对于“推荐”来说过于弱小，也应将其包含在“所有相关”中。
例如，当任务涉及改进提示、示例、模式菜单、文档、UI 提示或面向提示的措辞时，应包含 enhance-prompt。
当用户要求改进提示、紧凑提示、澄清提示措辞、使提示/上下文更好或包括面向提示的措辞（如“修复此错误报告，使其更清晰...”）时，应包含 enhance-prompt 作为支持，用于提示结构和清晰度。
不要仅因为当前任务不是 Stitch UI 提示就将其排除在“所有相关”之外。
对于“推荐”，应包含 brainstorming，当任务需要策略、上下文分析、行为更改、功能更改、提示/上下文改进、报告框架或决定如何在执行之前塑造工作时。
“推荐”通常应包含可以显著改善输出质量的常见支持技能，而不仅仅是严格的领域技能。
by