Skill Router
Skill Router is a low-presence routing layer for skill-heavy environments.
Its job is not to repeat normal skill triggering. Its job is to help when skill choice itself becomes a meaningful decision.
For portable/public use, route by capability first, then resolve capability to installed skills. Do not assume one workspace's local skill names are universal.
Use this skill to decide, not to announce
When active, do not dump a list of installed skills.
Do not explain the skill ecosystem unless the user explicitly wants that.
Do not interrupt simple tasks just to mention skills.
Instead, answer one question:
Given the current task, which installed skill is most worth using right now?
For portable use, infer likely fit from installed skill names and descriptions at runtime. Use local maps only as optional shortcut layers, not as universal truth. If no strong installed match exists, do not fake one; fall back to general guidance or discovery.
Only intervene when routing is genuinely useful
Typical high-value situations:
- - the user explicitly asks whether a relevant skill already exists
- the user asks which skill should be used
- multiple installed skills could plausibly fit
- an installed skill is easy to forget, but would clearly reduce wasted work
- the task is about installing or finding new skills, and existing skills should be checked first
Do not intervene just because a skill could theoretically apply.
If the default trigger path is already obvious and sufficient, stay out of the way.
If normal skill triggering already solved the task cleanly, Skill Router adds no value and should remain silent.
Core routing order
Always prefer this order:
- 1. installed strong match
- installed combination of skills, if one alone is not enough
- installed general fallback
- only then route to discovery / installation of something new
Skill Router exists to improve reuse of existing skills before expanding the skill set.
When no strong installed match exists, route to discovery rather than pretending capability already exists.
Even if the user explicitly asks to find or install a new skill, still prefer reuse first when an installed skill is already sufficient for the task.
If an installed skill can complete the task without clearly increasing failure risk or wasted work, do not trigger discovery just because another skill might be more specialized or more novel.
Follow references/resolution-order.md when the ranking is not obvious.
Output rules
Keep routing advice short, concrete, and low-noise.
Default output shape:
- 1. current best skill choice
- why this is the best fit
- optional backup choice, only if actually helpful
- immediate next step
Compression rule
If a good routing answer fits in one or two sentences, stop there.
Do not visibly expand into framework language.
Do not expose capability-taxonomy or routing-theory language unless the user explicitly asks for design detail.
Examples of good outputs:
- - "This is a browser-control task. We already have
pinchtab-browser; use that instead of a generic browser workflow." - "I don't see a strong installed match for this yet. Start with
find-skills; if a candidate comes from an unfamiliar source, run skill-vetter before installing it." - "For this GitHub task,
github is the right default. Use clawhub only if the task is specifically about skill publishing."
Examples of bad outputs:
- - long lists of every related skill
- repeating what the user already knows
- suggesting new skill installation before checking existing skills
- showing routing theory when one short recommendation would do
References
Read references/capability-taxonomy.md first when you need to map a task to a capability rather than jump to a skill name.
Read references/resolution-order.md when multiple installed skills could fit.
Read references/publish-safe-runtime-contract.md to keep routing portable and grounded in the user's actual installed environment.
Read references/task-to-skill-map.md only as a workspace-specific shortcut map for the current environment.
Read references/local-overrides-example.md when thinking about local preferences versus public defaults.
Read references/reminder-policy.md when deciding whether to stay silent or give a light reminder.
Read references/micro-routing-examples.md to keep discovery-vs-reuse decisions stable.
Final rule
Skill Router succeeds when it reduces cognitive load.
If it makes the task feel heavier, it is routing badly.
技能路由器
技能路由器是一个面向技能密集型环境的低侵入性路由层。
它的职责不是重复常规技能触发逻辑,而是在技能选择本身成为有意义决策时提供帮助。
在便携/公开场景下使用时,首先按能力进行路由,再将能力解析为已安装的技能。不要假设某个工作空间的本地技能名称具有通用性。
使用本技能进行决策,而非宣告
激活时,不要罗列已安装的技能列表。
除非用户明确要求,否则不要解释技能生态系统。
不要仅仅为了提及技能而打断简单任务。
相反,回答一个问题:
针对当前任务,哪个已安装的技能最值得现在使用?
在便携场景下,根据运行时已安装的技能名称和描述推断最可能的匹配。仅将本地映射作为可选的快捷层使用,而非通用真理。如果不存在强匹配的已安装技能,不要伪造匹配;应回退到通用指导或发现流程。
仅在路由确实有用时介入
典型的高价值场景:
- - 用户明确询问是否已存在相关技能
- 用户询问应该使用哪个技能
- 多个已安装技能都可能适用
- 某个已安装技能容易被遗忘,但能明显减少无效工作
- 任务涉及安装或寻找新技能,且应先检查已有技能
不要仅仅因为某个技能理论上可能适用就介入。
如果默认触发路径已经明确且足够,请保持不干涉。
如果常规技能触发已经干净地解决了任务,技能路由器不增加价值,应保持沉默。
核心路由顺序
始终优先遵循以下顺序:
- 1. 已安装的强匹配
- 已安装的技能组合(如果单一技能不足)
- 已安装的通用回退
- 最后才路由到发现/安装新技能
技能路由器存在的意义是在扩展技能集之前提高现有技能的复用率。
当不存在已安装的强匹配时,路由到发现流程,而不是假装能力已经存在。
即使用户明确要求寻找或安装新技能,如果已安装技能足以完成任务,仍应优先复用。
如果已安装技能能够完成任务且不会明显增加失败风险或无效工作,不要因为另一个技能可能更专业或更新颖而触发发现流程。
当排序不明确时,请参考references/resolution-order.md。
输出规则
保持路由建议简短、具体且低噪音。
默认输出结构:
- 1. 当前最佳技能选择
- 为什么这是最佳匹配
- 可选的备选方案(仅当确实有帮助时)
- 立即执行的下一步
压缩规则
如果好的路由答案可以用一两句话表达,就此打住。
不要明显扩展为框架语言。
不要暴露能力分类或路由理论语言,除非用户明确要求设计细节。
良好输出示例:
- - 这是一个浏览器控制任务。我们已经有pinchtab-browser;使用它而不是通用浏览器工作流。
- 我还没有看到已安装的强匹配。从find-skills开始;如果候选技能来自不熟悉的来源,在安装前运行skill-vetter。
- 对于这个GitHub任务,github是正确的默认选择。只有当任务专门涉及技能发布时,才使用clawhub。
不良输出示例:
- - 列出所有相关技能的冗长列表
- 重复用户已经知道的内容
- 在检查已有技能之前建议安装新技能
- 当一句简短推荐就足够时展示路由理论
参考资料
当需要将任务映射到能力而不是直接跳到技能名称时,首先阅读references/capability-taxonomy.md。
当多个已安装技能都可能适用时,阅读references/resolution-order.md。
阅读references/publish-safe-runtime-contract.md以保持路由的便携性并基于用户实际的已安装环境。
仅作为当前工作空间的特定快捷映射,阅读references/task-to-skill-map.md。
当考虑本地偏好与公共默认值时,阅读references/local-overrides-example.md。
当决定是保持沉默还是给出轻微提醒时,阅读references/reminder-policy.md。
阅读references/micro-routing-examples.md以保持发现与复用决策的稳定性。
最终规则
当技能路由器减轻认知负担时,它就是成功的。
如果它让任务感觉更沉重,那就是路由不佳。