技能路由引擎

要解决的问题

Agent 拿到任务的第一反应通常是直接动手。但很多任务本身已经隐含了该走哪条路径：一次生产事故需要的是系统性调试流程，不是快速打补丁；涉及认证的需求需要从一开始就带安全审计思维，而不是写完功能再回头看。反过来，把简单任务也塞进重型流程，每次对话都要为此付出额外开销。

Skill Router 补的就是这个决策真空：把「这个任务该走哪条路」变成一次 5 秒完成的显式分类，而不是留给模型临场判断。

路由如何工作

核心是三问分类，在每个非平凡任务执行前运行。它把任务映射到 Skill + Agent + Model 三元组，并附带一个 Thinking 深度前缀，输出固定为可 grep 的 [skill-router] 行加 ▶ 标记。

分类结果落入三条路径：

• BROKEN：错误、崩溃、测试失败、性能回退、安全问题、构建失败、生产事故。多数走 systematic-debugging + general-purpose + sonnet；生产事故升级到 opus 并使用 ultrathink。
• BUILD：多文件改动或新功能。UI 组件走 frontend-design，API 端点走 feature-dev，Schema 走 db-expert，认证/权限走 brainstorming → security。
• OPERATE：重构、补测试、性能优化、代码审查、部署，以及 2 个以上彼此独立的子任务并行调度。

复杂度规则是：一个领域对应一个 Skill，跨 2 个及以上领域时走链式路由，例如 test-runner → systematic-debugging。

最后还有一道完成门：任何声称「完成」之前，必须先过 verification-before-completion。

适用边界与注意点

不是所有任务都值得路由。一行修复、读代码、一个事实性问题、单条命令、3 步以内的操作应当跳过。把简单任务强行纳入流程，省下的 5 秒会以额外开销还回去。

路由结果静默有两种合法含义，不要一律解读成 OPERATE 或重构：

• 没有任何分类信号匹配，说明任务可能是简单的、探索性的或微不足道的；
• 用户使用了显式 slash 命令（如 /ship prod），说明他已经自行选定了 Skill。

输出格式是契约而不是建议：[skill-router] 行和 ▶ 标记必须原样输出，改写会让下游解析失效。Thinking 深度只有四种取值：none、think.、think hard.、ultrathink.，按路径表选择，不要自己发明。

路由表也不是终点。表里没有匹配项时，先跑目录检查再放弃；觉得自己已经知道该用哪个 Skill 时，也值得再跑一次——可能有更合适的替代。