Feature request: deferred/lazy-loaded skill catalog (analog of MCP's defer_loading)

Feature request: deferred/lazy-loaded skill catalog (analog of MCP's defer_loading)

Context

Follow-up to #82341 (per-subagent skill allowlisting). While investigating fixed per-subagent context overhead, we confirmed that MCP tools already support a deferred-loading pattern in this harness: MCP tool names appear in the system prompt, but full JSONSchema definitions are only fetched on demand via a search/lookup mechanism (referenced in-session as a ToolSearch-style tool, matching the general pattern of tool_search_tool_regex/tool_search_tool_bm25 + defer_loading: true used elsewhere in the Claude tool-use ecosystem).

Skills get no equivalent treatment. Every enabled skill's full description field (used for triggering/routing) is injected in full into every session and every subagent's system prompt, regardless of relevance to that particular conversation or task. For a user with ~60-70 active skills across personal + plugin catalogs, this alone measured at ~5-8k tokens of fixed overhead per context build (subagent or session), separate from and in addition to the already-filed per-subagent allowlisting gap in #82341.

Why this is architecturally plausible

Skill descriptions serve the same functional role as MCP tool names/descriptions serve today under deferred loading: a routing signal the model uses to decide what to invoke, with full detail (SKILL.md body / JSONSchema) only needed once actually selected. If MCP tools can defer full-schema loading behind a name+short-description index with on-demand fetch, an equivalent SkillSearch-style mechanism (keep skill names + short descriptions always resident, or even fully defer to a searchable index, fetching the routing-relevant detail only for candidate matches) seems structurally analogous.

Request

Explore a deferred-loading mode for the skill catalog, mirroring the existing MCP tool deferral mechanism:

• Skills catalog entries could be indexed/searchable (by name, keyword, or semantic match) rather than always fully enumerated in-context.
• Full SKILL.md content already loads lazily on invocation (existing behavior) — this request is specifically about the catalog listing/description overhead that's paid unconditionally per context build, not the skill body.
• Especially valuable for subagents, which currently pay this cost fresh on every single launch with no cache reuse (see #82341 and the discussion there on cache_creation_input_tokens overhead).

Impact

For users with large personal/plugin skill libraries running frequent subagent-based workflows, this is a fixed tax that scales with total installed skill count rather than with the actual task at hand, and currently has no user-facing lever except reducing the global skill count (trading away functionality session-wide to save context on individual subagent calls that may not need most of it).