当用户不确定该用哪个技能时，如何把请求路由到最匹配的技能

在用户询问「该用哪个技能」或需求模糊需要选择技能时，分析意图并推荐最贴切的技能。

适用场景

解决思路

1. 先做意图分析：识别用户想完成的任务类型、所处工作领域（web、mobile、data 等）以及任务复杂度（简单任务还是复杂工作流）。
2. 再做技能匹配：用关键词匹配对比请求关键词与技能描述，用语义相似度理解请求背后的含义，并结合项目状态与历史操作做上下文感知。
3. 当请求含糊时进行交互式澄清，提出有针对性的问题：主要目标是什么、期望什么类型的输出、是否有特定约束或偏好。
4. 给出推荐并执行：展示技能名称与简要描述、说明为何契合当前请求，并提供继续执行或查看替代方案的选项。
5. 按固定输出格式推荐：标题为「Recommended Skill: {skill-name}」，附上契合原因、一句话技能说明、适用场景，最后询问是否激活该技能或查看其他选项。
6. 遵循「先宽后窄」原则：先用通用类别问题开场，再根据回答逐层细化到具体技能。
7. 解释推荐理由：告诉用户为什么推荐某个技能，用透明性建立信任。
8. 提供替代方案：给出首选推荐的同时，如适用再提 1-2 个备选。
9. 处理边界情况：若没有完全契合的技能，推荐最接近的匹配；若直接提供通用帮助更好，则不用特定技能。
10. 从上下文学习：参考之前的交互，并记住用户偏好用于后续路由。
11. 使用语义路由处理关键词不直接匹配的情况，例如「clean up my code」→ refactoring-specialist、「make my app faster」→ performance-engineer、「check for security issues」→ security-auditor、「resume this interrupted workflow」→ long-task-coordinator。
12. 为复杂工作流建议多技能编排，例如新功能：architecting-solutions → debugger → code-reviewer；API 项目：api-designer → api-documenter → test-automator；生产就绪：security-auditor → performance-engineer → deployment-engineer。
13. 标注推荐置信度：High 表示关键词直接匹配、意图清晰；Medium 表示语义相似、合理推断；Low 表示请求含糊、需要澄清。
14. 做错误恢复：若推荐的技能不契合，先承认不匹配，再追问以细化理解，提供替代推荐，必要时回退到通用协助。
15. 使用交互式问题模板：目标澄清（想达成什么、理想结果是什么）、领域识别（属于开发/测试/文档/部署哪块，是在处理代码/API/基础设施还是其他）、阶段评估（处于规划/实现/测试/维护哪个阶段）、偏好确认（想要快速方案还是全面方案、是否使用特定工具或框架）。
16. 不要假设当前会话中不可见的 Claude Code、Codex、Gemini 或 DeepSeek Harness 能力，只推荐当前 host 暴露的技能。
17. 可参考技能目录按类别匹配：Meta 与工作流、核心开发、文档与测试、架构与 DevOps、规划与分析、设计与 UX。

适用边界 · 注意事项

• 当前会话中看不到的技能或宿主能力不应假设存在，不要据此推荐。
• 当直接提供通用协助比套用某个技能更合适时，不必强行路由到技能。