hermes-tool-router-onboarding

Hermes Tool Router — First-Run Onboarding

This skill is the onboarding surface for the hermes-tool-router plugin (the standalone pre-turn tool router). Use it once per fresh profile: explain what the router does, offer the optional classifier API key exactly once, and verify the router is live. It is written against the plugin's real behavior — read config.yaml and README.md in the plugin checkout before changing anything.

The router is disabled by default and experimental. Test it on a separate Hermes profile first; do not install it directly on a primary profile.

1. What the router does

Before the first provider request of a session, the router predicts which toolsets the request needs and narrows the live tool surface to only those toolsets, cutting first-turn token and tool-schema overhead. Key behaviors (all in this plugin, v0.2+):

• Pre-turn toolset prediction: deterministic intent rules classify the user's first turn and load only the toolsets that request needs (hook: pre_llm_call). Measured schema reductions in the README baselines are large, but they are estimator results, not billing receipts — treat them as indicative, never as a guarantee.
• Session-sticky surface: later turns reuse the initial routed surface instead of reclassifying and shrinking it every turn. This fixed behavior keeps the surface stable across the session.
• Monotonic expansion: if a pruned registered tool is requested later, its owning toolset is added permanently for the session and is never re-pruned. This fixed behavior comes from the tool_request middleware and request_toolset fallback.
• Fail open: uncertainty, invalid classifier output, missing confidence, timeout, registry mismatch, or unsupported runtime keeps the full tool surface. Nothing is ever pruned unless the router is confident (fail_open: true, confidence_threshold: 0.90).

The router is disabled by default (global.enabled: false). It must be enabled explicitly (globally or per profile) before any of the above runs.