[GH-ISSUE #24313] feat: introduce built-in tool for dynamic skill discovery #58928

Open
opened 2026-05-06 00:29:11 -05:00 by GiteaMirror · 0 comments
Owner

Originally created by @gvd22 on GitHub (May 2, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24313

Check Existing Issues

  • I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

  • I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

In setups where models are managed by admins and users do not have permission to edit model abstractions, users can still create skills, prompts, and knowledge.

However, skills are effectively unusable in this setup.

Why:

  • Skills must currently be attached to a model
  • Attaching skills requires model edit permissions
  • Users without these permissions cannot use their own skills with shared models

Result:

  • Skills can be created but not used
  • Admins must preconfigure skills per model
  • This does not scale and adds operational overhead

Observation:
Knowledge already follows a better pattern:

  • No knowledge attached → model can discover accessible knowledge
  • Knowledge attached → scope is restricted
  • Access checks still apply

A comparable mechanism does not exist for skills.

Desired Solution you'd like

Introduce a built-in tool for agentic skill discovery.

Behavior:

  • Tool is automatically available when:

    • native tool calling is enabled
    • skills feature is enabled
    • no explicit skills are attached to the model
  • The tool returns:

    • name
    • short description
  • Full skill content is loaded via view_skill

    • includes access control checks
  • Scoping:

    • No attached skills → return all accessible skills
    • Attached skills → restrict to those skills

Outcome:

  • Models can discover skills dynamically
  • Users can use skills without model edit permissions
  • Enables a more agentic workflow aligned with knowledge retrieval

Compatibility:

  • Explicitly attached skills continue to work
  • $<skill-name> still works
  • view_skill remains unchanged, besides the prompt description maybe.

Alternatives Considered

1. $<skill-name> invocation

  • Requires users to:
    • know skills exist
    • know which skill to use
    • know the exact name
  • Not suitable for most office end users

2. Custom models per use case

  • Requires admin maintenance
  • Does not scale

Additional Context

We already had an initial discussion on this topic here: https://github.com/open-webui/open-webui/discussions/23641#discussioncomment-16777150

Originally created by @gvd22 on GitHub (May 2, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24313 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description In setups where models are managed by admins and users do not have permission to edit model abstractions, users can still create skills, prompts, and knowledge. However, skills are effectively unusable in this setup. **Why:** - Skills must currently be attached to a model - Attaching skills requires model edit permissions - Users without these permissions cannot use their own skills with shared models **Result:** - Skills can be created but not used - Admins must preconfigure skills per model - This does not scale and adds operational overhead **Observation:** Knowledge already follows a better pattern: - No knowledge attached → model can discover accessible knowledge - Knowledge attached → scope is restricted - Access checks still apply A comparable mechanism does not exist for skills. ### Desired Solution you'd like Introduce a built-in tool for agentic skill discovery. **Behavior:** - Tool is automatically available when: - native tool calling is enabled - skills feature is enabled - no explicit skills are attached to the model - The tool returns: - name - short description - Full skill content is loaded via `view_skill` - includes access control checks - Scoping: - No attached skills → return all accessible skills - Attached skills → restrict to those skills **Outcome:** - Models can discover skills dynamically - Users can use skills without model edit permissions - Enables a more agentic workflow aligned with knowledge retrieval **Compatibility:** - Explicitly attached skills continue to work - `$<skill-name>` still works - `view_skill` remains unchanged, besides the prompt description maybe. ### Alternatives Considered **1. `$<skill-name>` invocation** - Requires users to: - know skills exist - know which skill to use - know the exact name - Not suitable for most office end users **2. Custom models per use case** - Requires admin maintenance - Does not scale ### Additional Context We already had an initial discussion on this topic here: https://github.com/open-webui/open-webui/discussions/23641#discussioncomment-16777150
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#58928