Unified Discovery Router

Problem

When working with SkillHub finance skills, the blocker is often not syntax but routing: deciding whether a natural-language request should go to wm-valuation, wm-debt-safety, a symbol lookup, an industry/index search, a metric definition, or an XS function signature. Browsing skill lists manually can miss default domains, fallback rules, and related fields, and can encourage brittle patterns such as raw XS first, third-party substitutes, or accidentally invoking run on this discovery pack.

How It Works

Unified Discovery Router is a routing entry point that turns a user’s original phrase or keyword into the next executable step. It searches multiple domains by default, including skill, symbol, metric, vfunc, index, industry, screener, and strategy. If domain=skill is returned, take the id and call the matching official skill with $WM run. For company names, securities codes, industries, indices, metric formulas, or function signatures, the result can include id, definition, formula, example_call_xs, call_spec, require, and prefer_skill, which helps align the next call.

High-frequency intents also have a session-level fast path: within the same session, if dividends, valuation, debt, notices, screening, or similar intents have already been mapped to a skill, repeated discovery is unnecessary. For vfunc domain libraries such as notice.*, filings.*, and kline.*, read example_call_xs and call_spec first. If prefer_skill exists and the user wants the product outcome, route to that L1 skill first.

Boundaries

It solves routing and field alignment, not full execution. Use wm-screen-index to run screening conditions. If a securities code is already known and only market or financial card output is needed, call the matching L1 directly. For short XS code, use this interface to confirm $ metrics, function names, and require before entering wm-xs. If there are 0 hits, rephrase or mark the gap as uncovered instead of inventing skills, codes, or APIs.