[GH-ISSUE #19941] feat: Support for (Anthropic/OpenAI) skills and SKILL.md #57708

Closed
opened 2026-05-05 21:27:27 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @EmilStenstrom on GitHub (Dec 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19941

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

First of all, thank you for all the work you’re putting into Open WebUI — it’s an amazing project, and I really appreciate that you are sharing this project with the community as open source.

I mainly use Open WebUI as my interface to Anthropic and OpenAI.

  • Anthropic has introduced Skills as folders on disk containing a Markdown file plus optional resources/scripts.
  • OpenAI now appears to be adopting a very similar model: in ChatGPT’s Code Interpreter environment there is a /home/oai/skills folder, where each Skill is likewise a folder with a Markdown file and optional extra resources/scripts. These are already used for things like spreadsheets, DOCX and PDFs.[1]

Right now, there’s no simple way to take advantage of these filesystem‑based Skills directly from Open WebUI. To use them, I have to work in provider‑specific environments (like Claude Code or ChatGPT’s Code Interpreter), or call the underlying APIs separately, which breaks the otherwise smooth workflow Open WebUI provides.

My main goal is to reuse the existing office/document Skills (for spreadsheets, DOCX, PDFs, etc.) that Anthropic and OpenAI already ship, from within Open WebUI — ideally via the same simple “drop a folder = new Skill” pattern.

Desired Solution you'd like

Instead of a complex UI for managing Skills, a much simpler and more natural API would be a filesystem‑based Skills interface, aligned with how both Anthropic and OpenAI are approaching Skills (folders with Markdown + optional resources).

High‑level idea:

  1. Skills as folders on disk

    • Open WebUI watches a configurable skills/ directory on the server.
    • Each subfolder represents a Skill, for example:
      • skills/office-docs/
      • skills/pdf-tools/
    • A Skill folder contains:
      • A main description file (e.g., SKILL.md or skill.md) describing:
        • What the Skill does.
        • How/when it should be used.
      • Optional supporting files: templates, small scripts, helper code, etc.

    This mirrors the pattern where a Skill is “just a folder with a Markdown file and some optional extra resources and scripts,” which is exactly what OpenAI is using in their /home/oai/skills directory for spreadsheet/DOCX/PDF Skills.

  2. Automatic discovery and registration

    • On startup (and possibly on change), Open WebUI:
      • Scans the skills/ directory.
      • Parses each Skill’s metadata (name, description, maybe tags like type: office-doc).
      • Registers these Skills as available capabilities for compatible models (Anthropic, OpenAI, etc.).
  3. Integration with the code‑execution feature

    • If the Open WebUI has code‑execution enabled, Skill folders could include scripts or helpers that run in that environment.
    • The model would:
      • Read the Skill’s Markdown description/resources.
      • Use the existing code‑execution feature to run any helper scripts where needed.
    • From the user’s perspective, the flow becomes:
      • “I ask for a Word/Excel/PowerPoint/PDF document → the model uses the relevant Skill from skills/ → a file appears as an attachment or download link in Open WebUI.”
  4. Very minimal UI surface

    • In model/preset settings:
      • A checkbox like: “Enable filesystem Skills from the skills/ folder for this model (where supported).”
      • A simple read‑only list of discovered Skills (name + short description) so users know what’s available?
    • No need initially for editing Skills in the UI; users can:
      • Add Skills by dropping new folders into skills/.
      • Update or remove them via the filesystem or version control.

The key idea is: if a platform already supports “Skills as folders with Markdown and resources” (like Anthropic and OpenAI now do), Open WebUI can expose those Skills just by mounting or mirroring a skills/ directory and letting the model read/use them.[1] Office/document Skills (spreadsheets, DOCX, PDFs) would be the first and most obviously useful case.

Alternatives Considered

  • Custom pipelines inside Open WebUI

    • It’s already possible to build custom pipelines/flows in Open WebUI that:
      • Call out to model APIs,
      • Run code,
      • Post‑process results (e.g., generate documents).
    • This is powerful but:
      • Requires more bespoke wiring for each use case,
      • Makes it harder to reuse the same “skill” in different models or projects,
      • Doesn’t naturally align with the “drop a folder and you’re done” pattern Anthropic/OpenAI are adopting.
  • Re‑implementing Skills as “tools”

    • Another option is to expose equivalent functionality as standard tools / function calls:
      • Define tools for “create_docx”, “convert_to_pdf”, etc.
      • Have the model call those tools explicitly.
    • This works, but:
      • You lose the neat convention of Skills being self‑contained folders with Markdown + resources,
      • You’d need a separate tool definition layer in addition to whatever Anthropic/OpenAI are already shipping as Skills,
      • It may duplicate rather than reuse the existing Skill assets.
  • Implementing an MCP server that provides document Skills

    • With MCP, you could build a dedicated server that exposes document/office capabilities and connect it to Open WebUI.
    • This is flexible and future‑proof, but:
      • It’s more infrastructure to run and maintain (a separate server/process),
      • It’s a heavier‑weight solution than simply mounting a skills/ folder,
      • It doesn’t automatically take advantage of the exact same filesystem Skills layout that Anthropic/OpenAI are already using.

By contrast, a filesystem‑based Skills directory in Open WebUI aims to be the lightest possible integration: reuse the same “folders with Markdown + resources” convention that Anthropic and OpenAI already use, without needing extra pipeline logic, tool definitions, or a separate MCP service.

Additional Context

I completely understand if this isn’t a priority or doesn’t fit your roadmap right now; I just wanted to share the idea in case a minimal filesystem‑based Skills integration feels like a good fit for Open WebUI’s direction.

Originally created by @EmilStenstrom on GitHub (Dec 14, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/19941 ### 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 First of all, thank you for all the work you’re putting into Open WebUI — it’s an amazing project, and I really appreciate that you are sharing this project with the community as open source. I mainly use Open WebUI as my interface to Anthropic and OpenAI. - Anthropic has introduced **Skills** as folders on disk containing a Markdown file plus optional resources/scripts. - OpenAI now appears to be adopting a very similar model: in ChatGPT’s Code Interpreter environment there is a `/home/oai/skills` folder, where each Skill is likewise a folder with a Markdown file and optional extra resources/scripts. These are already used for things like spreadsheets, DOCX and PDFs.[1] Right now, there’s no simple way to take advantage of these filesystem‑based Skills directly from Open WebUI. To use them, I have to work in provider‑specific environments (like Claude Code or ChatGPT’s Code Interpreter), or call the underlying APIs separately, which breaks the otherwise smooth workflow Open WebUI provides. My main goal is to **reuse the existing office/document Skills** (for spreadsheets, DOCX, PDFs, etc.) that Anthropic and OpenAI already ship, from within Open WebUI — ideally via the same simple “drop a folder = new Skill” pattern. ### Desired Solution you'd like Instead of a complex UI for managing Skills, a much simpler and more natural API would be a **filesystem‑based Skills interface**, aligned with how both Anthropic and OpenAI are approaching Skills (folders with Markdown + optional resources). High‑level idea: 1. **Skills as folders on disk** - Open WebUI watches a configurable `skills/` directory on the server. - Each subfolder represents a Skill, for example: - `skills/office-docs/` - `skills/pdf-tools/` - A Skill folder contains: - A main description file (e.g., `SKILL.md` or `skill.md`) describing: - What the Skill does. - How/when it should be used. - Optional supporting files: templates, small scripts, helper code, etc. This mirrors the pattern where a Skill is “just a folder with a Markdown file and some optional extra resources and scripts,” which is exactly what OpenAI is using in their `/home/oai/skills` directory for spreadsheet/DOCX/PDF Skills. 2. **Automatic discovery and registration** - On startup (and possibly on change), Open WebUI: - Scans the `skills/` directory. - Parses each Skill’s metadata (name, description, maybe tags like `type: office-doc`). - Registers these Skills as available capabilities for compatible models (Anthropic, OpenAI, etc.). 3. **Integration with the code‑execution feature** - If the Open WebUI has code‑execution enabled, Skill folders could include scripts or helpers that run in that environment. - The model would: - Read the Skill’s Markdown description/resources. - Use the existing code‑execution feature to run any helper scripts where needed. - From the user’s perspective, the flow becomes: - “I ask for a Word/Excel/PowerPoint/PDF document → the model uses the relevant Skill from `skills/` → a file appears as an attachment or download link in Open WebUI.” 4. **Very minimal UI surface** - In model/preset settings: - A checkbox like: “Enable filesystem Skills from the `skills/` folder for this model (where supported).” - A simple read‑only list of discovered Skills (name + short description) so users know what’s available? - No need initially for editing Skills in the UI; users can: - Add Skills by dropping new folders into `skills/`. - Update or remove them via the filesystem or version control. The key idea is: **if a platform already supports “Skills as folders with Markdown and resources” (like Anthropic and OpenAI now do), Open WebUI can expose those Skills just by mounting or mirroring a `skills/` directory and letting the model read/use them.**[1] Office/document Skills (spreadsheets, DOCX, PDFs) would be the first and most obviously useful case. ### Alternatives Considered - **Custom pipelines inside Open WebUI** - It’s already possible to build custom pipelines/flows in Open WebUI that: - Call out to model APIs, - Run code, - Post‑process results (e.g., generate documents). - This is powerful but: - Requires more bespoke wiring for each use case, - Makes it harder to reuse the same “skill” in different models or projects, - Doesn’t naturally align with the “drop a folder and you’re done” pattern Anthropic/OpenAI are adopting. - **Re‑implementing Skills as “tools”** - Another option is to expose equivalent functionality as standard tools / function calls: - Define tools for “create_docx”, “convert_to_pdf”, etc. - Have the model call those tools explicitly. - This works, but: - You lose the neat convention of Skills being self‑contained folders with Markdown + resources, - You’d need a separate tool definition layer in addition to whatever Anthropic/OpenAI are already shipping as Skills, - It may duplicate rather than reuse the existing Skill assets. - **Implementing an MCP server that provides document Skills** - With MCP, you could build a dedicated server that exposes document/office capabilities and connect it to Open WebUI. - This is flexible and future‑proof, but: - It’s more infrastructure to run and maintain (a separate server/process), - It’s a heavier‑weight solution than simply mounting a `skills/` folder, - It doesn’t automatically take advantage of the exact same filesystem Skills layout that Anthropic/OpenAI are already using. By contrast, a filesystem‑based Skills directory in Open WebUI aims to be the lightest possible integration: **reuse the same “folders with Markdown + resources” convention** that Anthropic and OpenAI already use, without needing extra pipeline logic, tool definitions, or a separate MCP service. ### Additional Context I completely understand if this isn’t a priority or doesn’t fit your roadmap right now; I just wanted to share the idea in case a minimal filesystem‑based Skills integration feels like a good fit for Open WebUI’s direction.
Author
Owner

@owui-terminator[bot] commented on GitHub (Dec 14, 2025):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

  1. #19876 feat: Support "Embeddable Chat JS Widget for Custom-Models" for individual websites
    by alperreha • Dec 11, 2025

  2. #19908 feat: Supports OpenAI-Response format API and related parameters
    by daxiass • Dec 12, 2025


💡 Tips:

  • If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
  • If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

<!-- gh-comment-id:3650442001 --> @owui-terminator[bot] commented on GitHub (Dec 14, 2025): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#19876](https://github.com/open-webui/open-webui/issues/19876) **feat: Support "Embeddable Chat JS Widget for Custom-Models" for individual websites** *by alperreha • Dec 11, 2025* 2. [#19908](https://github.com/open-webui/open-webui/issues/19908) **feat: Supports OpenAI-Response format API and related parameters** *by daxiass • Dec 12, 2025* --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#57708