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.
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @gvd22 on GitHub (May 2, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24313
Check Existing Issues
Verify Feature Scope
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:
Result:
Observation:
Knowledge already follows a better pattern:
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:
The tool returns:
Full skill content is loaded via
view_skillScoping:
Outcome:
Compatibility:
$<skill-name>still worksview_skillremains unchanged, besides the prompt description maybe.Alternatives Considered
1.
$<skill-name>invocation2. Custom models per use case
Additional Context
We already had an initial discussion on this topic here: https://github.com/open-webui/open-webui/discussions/23641#discussioncomment-16777150