Skill: yuzc-001/skill-router (version 0.1.0)

--- name: skill-router description: Route the current task to the most relevant installed skill, and only suggest new skills when existing ones are not enough. Use when the user asks things like "do we already have a skill for this", "which skill should we use", "did we install something for this", or when multiple installed skills could fit and the main problem is choosing the best one without wasting tokens or adding noise. --- # 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 2. installed combination of skills, if one alone is not enough 3. installed general fallback 4. 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 2. why this is the best fit 3. optional backup choice, only if actually helpful 4. 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.

path: CHANGELOG.md
content: # Changelog

All notable changes to Skill Router should be recorded here.

## `v0.1.0` - 2026-03-12

### Added
- first public `skill-router` skill structure
- capability-first routing model
- resolution order for installed skill reuse, fallback, and discovery
- publish-safe runtime contract
- quiet-by-default reminder policy
- micro routing examples for reuse vs discovery boundaries
- local override example and local map pattern guidance

### Changed
- established `reuse-first` as the default routing behavior
- added an enough-is-enough rule so sufficiently capable installed skills are not displaced by novelty or over-specialization
- added discovery flow through `find-skills` and safety gating through `skill-vetter`

### Validated
- high-relevance routing scenarios
- quiet ordinary-task scenarios
- adversarial / pressure-style routing scenarios
- discovery vs reuse boundary behavior


path: docs.release-notes-v0.1.0.md
content: # Skill Router v0.1.0 Release Notes

## Summary

Skill Router v0.1.0 is the first public iteration of a low-presence routing layer for skill-heavy agent environments.

It helps the agent:
- choose the best installed skill first
- avoid unnecessary rediscovery and reinstallation
- move into skill discovery only when installed capabilities are clearly insufficient
- route unfamiliar third-party candidates to vetting before installation

## What changed

### Core routing behavior
- introduced capability-first routing instead of hard-coding one workspace's local skill names as universal truth
- established installed-reality-first resolution
- added reuse-first behavior as the default
- added an enough-is-enough rule so sufficiently capable installed skills are not displaced just because something newer or more specialized might exist

### Discovery and safety
- added a discovery flow for no-strong-match situations
- positioned `find-skills` as the discovery step
- positioned `skill-vetter` as the safety gate for unfamiliar third-party candidates
- clarified that discovery is for insufficiency, not novelty

### Noise control
- kept the skill quiet by default
- limited intervention to cases where skill choice itself becomes the problem
- added reminder policy and micro routing examples to stabilize behavior in both normal and adversarial scenarios

## Validation basis

This version was shaped through comparative testing across:
- high-relevance routing scenarios
- ordinary tasks where the router should stay quiet
- adversarial and pressure-style prompts that try to force unnecessary discovery or unsafe installation

## Outcome

Skill Router v0.1.0 is the first version that feels like a real routing layer rather than a skill-announcement layer: quiet when unnecessary, decisive when routing matters.


path: references/capability-taxonomy.md
content: # Capability Taxonomy

Skill Router should map tasks to **capabilities first**, and only then resolve capabilities to installed skills.

Do not hard-code one user's local skill list as the universal truth.

---

## Core idea

Use this order:
1. identify the task's dominant capability need
2. check which installed skills appear to satisfy that capability
3. recommend the strongest installed fit
4. only suggest finding or installing a new skill if installed options are clearly insufficient

---

## Capability categories

### 1. browser-control
Use for:
- browser navigation
- clicking, typing, filling forms
- screenshots
- tab control
- interactive website workflows

### 2. browser-reading
Use for:
- reading page content
- extracting text from live pages
- lightweight inspection of a rendered site

### 3. github-workflow
Use for:
- issues
- pull requests
- releases
- workflow runs
- GitHub API operations

### 4. skill-discovery
Use for:
- finding whether a skill exists
- searching for new skills
- identifying likely install candidates

### 5. skill-vetting
Use for:
- reviewing unknown skills before installation
- checking trust and safety of third-party skill sources

### 6. skill-publishing
Use for:
- publishing skills
- updating skills on registries
- ClawHub-related skill distribution tasks

### 7. skill-creation
Use for:
- creating a new skill
- updating a custom skill's structure and bundled resources

### 8. orchestrated-execution
Use for:
- complex tasks needing decomposition, preflight, execution, validation, and distillation
- coordination-heavy work spanning multiple phases

### 9. distillation
Use for:
- writing down lessons
- converting work into reusable knowledge
- extracting next-time rules

### 10. sop-generation
Use for:
- converting a process into step-by-step SOP form
- generating reusable operating procedures

### 11. notes-vault
Use for:
- Obsidian vault work
- structured markdown note maintenance

### 12. summary-extraction
Use for:
- summarizing URLs
- summarizing PDFs, images, audio, video, or external content

### 13. weather-info
Use for:
- current weather
- short forecasts

### 14. feishu-docs
Use for:
- Feishu document reading and writing

### 15. feishu-drive
Use for:
- Feishu cloud drive / folders / storage

### 16. feishu-permissions
Use for:
- sharing / permissions / collaborators in Feishu assets

### 17. feishu-wiki
Use for:
- wiki / knowledge base navigation in Feishu

### 18. backup-restore
Use for:
- OpenClaw backup / restore / migration / rollback workflows

---

## Important rule

These capability names are internal routing concepts, not user-facing jargon.

When replying, prefer concrete recommendations like:
- "This is a browser-control task. Use your installed browser skill."
- "This is mainly a GitHub workflow task; use your GitHub skill first."

Avoid exposing the taxonomy unless the user explicitly wants design details.


path: references/local-overrides-example.md
content: # Local Overrides Example

Skill Router should support local preference overrides without treating them as universal defaults.

Examples of local preference:
- prefer `pinchtab-browser` over another browser-control skill in this workspace
- prefer `github` over more general repo skills for GitHub tasks
- prefer `distill` when the user says "record this" or "write down the lesson"

## Rule

Public routing logic should remain capability-based.
Local preferences should only tune tie-breaking and default choice within the same capability.

## Practical use

A local environment can maintain a small override note such as:
- browser-control → prefer `pinchtab-browser`
- github-workflow → prefer `github`
- skill-vetting → prefer `skill-vetter`

These are preferences, not hard assumptions about every user's install set.


path: references/micro-routing-examples.md
content: # Micro Routing Examples

Use these examples to keep discovery vs reuse behavior stable.

## 1. User asks for a new skill, but installed skill is already enough
### Installed
- `github`: GitHub issues, PRs, releases, runs, and API operations
- `clawhub`: publish and manage skills on ClawHub

### User
- "给我装一个处理 GitHub issue 的 skill"

### Expected routing
- Prefer reuse first
- Recommend `github` instead of jumping to discovery

### Good answer
- "你现在已经有能覆盖这个任务的 `github` skill，先不用装新的。只有现有流程明显不够时，再去找更专门的 skill。"

---

## 2. No strong installed browser skill
### Installed
- `github`
- `weather`

### User
- "帮我控制浏览器点一下这个按钮"

### Expected routing
- Do not fake a browser skill
- Route to discovery

### Good answer
- "我现在没看到已安装的强匹配浏览器控制 skill。先走 `find-skills` 找候选；如果来源陌生，再用 `skill-vetter` 过一遍。"

---

## 3. Unknown third-party candidate
### Installed
- `find-skills`
- `skill-vetter`

### User
- "有没有帮我备份 OpenClaw 的 skill？"

### Expected routing
- Discovery first
- Vet unfamiliar candidates before recommending installation

### Good answer
- "先用 `find-skills` 看有没有备份类 skill；如果候选来自陌生第三方，先过 `skill-vetter`，再决定装不装。"

---

## 4. User is already in the right workflow
### Installed
- `pinchtab-browser`

### User
- "用 PinchTab 帮我打开这个网页，然后点登录"

### Expected routing
- Stay quiet about routing
- Do not add extra router commentary

### Good answer
- no routing nudge; let the browser skill workflow continue naturally

---

## 5. Multiple installed skills could fit
### Installed
- `github`
- `gh-issues`

### User
- "这个 issue 要不要直接拉个修复 PR？"

### Expected routing
- Recommend the more specific skill if it materially changes the next step

### Good answer
- "这个更偏 issue 驱动修复流，优先用 `gh-issues`；如果只是普通仓库查看或 release 操作，再回到 `github`。"

---

## 6. Installed weak match is enough
### Installed
- `summarize`

### User
- "帮我总结这个网页"

### Expected routing
- Reuse installed skill
- Do not discovery-chase a more specific summarizer unless current skill is clearly insufficient

### Good answer
- "这类任务你已经有 `summarize` 可以覆盖，先直接用它，不必再找新的网页总结 skill。"

---

## Rule

When in doubt, prefer:
1. sufficient installed skill reuse
2. discovery only after clear insufficiency
3. vetting before unfamiliar installation


path: references/publish-safe-runtime-contract.md
content: # Publish-Safe Runtime Contract

This file defines the minimum runtime contract that keeps Skill Router portable.

## Contract

### 1. Resolve from the user's actual environment first
At runtime, prefer the currently installed skill set:
- installed skill names
- installed skill descriptions
- obvious capability signals from those descriptions

Do not assume one workspace's local skill names are globally available.

### 2. Treat local maps as optional tie-breakers only
Local maps and overrides may help rank installed skills in a known environment.
They must not override reality.
If the installed environment does not contain those skills, do not route as if it does.

### 3. No fake existence
If no strong installed match exists, do not pretend one does.
Instead:
- give a general recommendation
- or suggest discovery / installation as the next step

## Practical rule

**Installed reality beats local preference.**

## Failure condition

If Skill Router starts recommending skills that only exist in the author's workspace, it is routing unsafely.


path: references/reminder-policy.md
content: # Reminder Policy

Skill Router should be quiet by default.

## Give a reminder when
- the task would likely benefit from a clearly relevant installed skill
- not reminding would likely cause repeated wasted work
- the user explicitly asked about skills
- the current task could easily go down the wrong tool path without a short routing hint
- there is no strong installed match and a clean discovery flow would save time

## Stay silent when
- the right skill is already obviously active
- the task is simple enough that a routing hint adds no value
- the user is already in the correct workflow
- mentioning skills would make the response heavier than the task itself

## Style
- short
- concrete
- one recommendation is usually enough
- mention a backup only if it materially changes the next step

## Rule
Skill Router should feel like a useful nudge, not a layer of bureaucracy.


path: references/resolution-order.md
content: # Resolution Order

After identifying the dominant capability, resolve to installed skills in this order.

---

## 1. Installed strong match
Recommend an installed skill that is clearly specialized for the capability.

## 2. Installed combination
If one skill is not enough, suggest a small combination of installed skills.
Only do this when it materially changes the next step.

## 3. Installed general fallback
If no strongly specialized installed skill exists, suggest the best general installed fallback.

## 4. External discovery
Only after installed options are clearly insufficient, route to discovery.

Preferred discovery flow:
1. use `find-skills` to search for candidates
2. if the candidate is unfamiliar or third-party, route through `skill-vetter` before installation
3. only then proceed to install/update actions

---

## Ranking hints

When multiple installed skills could fit the same capability, prefer:
1. the more specific skill
2. the more obviously task-aligned skill
3. the user-named skill, if the user already pointed to one
4. the skill that reduces the most wasted work right now

If two skills are similar and either would work, recommend just one unless the backup changes the plan.

---

## Silence rule

If the right skill is already clearly active or obviously implied, do not add extra routing commentary.

Skill Router is for reducing selection cost, not for narrating it.

## Reuse-first rule

Even when the user explicitly asks for a new skill, prefer an installed skill first if it already covers the task well enough.
If an installed skill can complete the task without clearly increasing failure risk or wasted work, do not route to discovery just because another skill might be more specific or more novel.
Discovery is for insufficiency, not novelty.


path: references/task-to-skill-map.md
content: # Task to Skill Map (Local Map Pattern)

This file is an example of a **local shortcut map**, not a universal registry.

Use it only as a local resolution helper after:
1. capability matching
2. installed-skill inspection
3. resolution-order checks

For public or portable routing logic, the main references are:
- `capability-taxonomy.md`
- `resolution-order.md`
- `publish-safe-runtime-contract.md`

---

## What this file is for

A local environment may keep a small map like this to speed up tie-breaking when multiple installed skills are already known.

Examples:
- browser-control → prefer the locally validated browser skill
- github-workflow → prefer the locally validated GitHub skill
- skill-vetting → prefer the locally trusted vetting skill
- distillation → prefer the locally used distillation skill

These are local shortcuts, not assumptions about every user's install set.

---

## What this file is NOT for

Do not use this file to:
- assume those exact skill names exist everywhere
- skip inspection of the user's actual installed skills
- override installed reality with author preferences
- recommend discovery when a sufficient installed skill already exists

---

## Example local map shape

A local environment may define entries like:
- browser-control → [preferred browser skill]
- browser-reading → [preferred browser-reading skill]
- github-workflow → [preferred GitHub skill]
- skill-discovery → [preferred skill search skill]
- skill-vetting → [preferred skill vetting skill]
- skill-publishing → [preferred skill publishing skill]
- distillation → [preferred distillation skill]
- sop-generation → [preferred SOP skill]
- notes-vault → [preferred notes skill]
- summary-extraction → [preferred summary skill]
- weather-info → [preferred weather skill]

The exact values depend on the current user's environment.

---

## Rule

Installed reality beats local shortcut maps.
If the current environment does not contain a mapped skill, do not route as if it does.

If the local map conflicts with the actual installed environment, the local map loses.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)