Open WebUI Skills in 2026: Create, Auto-Discover, Share & Secure Reusable AI Workflows

Open WebUI 0.11.4 changes Skills from a simple prompt-library feature into a reusable layer for local AI workflows. The release adds automatic skill discovery, terminal-provided skills, terminal-level AGENTS.md instructions, and a /skills:create workflow that can turn a successful chat-and-terminal workflow into a reusable SKILL.md. The important part is not the command itself; it is understanding where skills live, how they are discovered, when their full instructions enter context, how they interact with tools, and how to keep shared skills from becoming an accidental security boundary.

This guide focuses on the current Open WebUI Skills model and the practical workflow around Open WebUI 0.11.4. It is intentionally different from a generic Open WebUI installation guide: the goal is to help you build, verify, share, troubleshoot and safely maintain reusable Skills for local AI agents.

What changed in Open WebUI Skills?

Open WebUI documents Skills as reusable Markdown-based instruction sets. A Skill is not itself an executable tool. It tells the model how to approach a task; tools such as Open Terminal provide the capability to actually run commands or access a workspace.

In Open WebUI 0.11.4, the Skills system became more agent-oriented in several important ways:

These capabilities are documented by Open WebUI in its Skills documentation and the 0.11.4 release notes. They should not be confused with claims that Skills can execute arbitrary code by themselves: Skills are instruction content, while executable operations still depend on enabled tools and their permissions.

How Open WebUI Skills work

1. A Skill is an instruction package

A basic Skill has a Markdown instruction file. Open WebUI's current documentation describes fields such as a human-readable name, a description and the full instructional content. Skills can also be imported and exported, and the broader Agent Skills format can include supporting directories such as scripts, references, templates and assets.

A useful Skill should answer a practical question such as:

• When should the agent use this workflow?
• What prerequisites must be present?
• Which commands or tools are safe and canonical?
• What sequence should the agent follow?
• What should it do when a command fails?
• How can it verify that the task actually succeeded?

A Skill that merely says “be good at Docker” is weak. A Skill that says “when debugging a Dockerized Django service, first inspect container state, then logs, then health endpoints, and never delete volumes without explicit confirmation” is much more operationally useful.

2. Explicit Skills versus discovered Skills

Open WebUI supports several ways to make Skills available. You can select a Skill from the chat interface, bind Skills to a model, or use the Skill discovery mechanism available to models with built-in tools.

The important distinction is context usage. With native function calling and built-in tools enabled, the model can receive a compact manifest containing Skill names and descriptions and load the full instructions on demand. A direct $ mention instead injects the full Skill into the current message context.

That means you should keep Skill descriptions precise. The description is not marketing copy; it is part of the routing signal that helps the model decide whether a Skill is relevant.

Creating a Skill from a successful chat

One of the most interesting additions in Open WebUI 0.11.4 is /skills:create.

If you have a connected terminal selected and have already completed a useful workflow in chat, you can type:

/skills:create

You can also give authoring guidance after the command. For example:

/skills:create
Create a reusable Django production troubleshooting skill.
Focus on safe diagnostics, Gunicorn, Nginx, systemd and PostgreSQL.
Never recommend destructive commands without explicit confirmation.
Include verification and rollback checks.

According to the Open WebUI documentation, the workflow creates a SKILL.md under the selected terminal's .agents/skills directory, with supporting material placed in directories such as scripts, references, templates or assets when appropriate.

This is valuable because the best source material for a Skill is often a workflow that has already been tested. Instead of trying to write a perfect Skill from scratch, solve the problem once, identify the reliable procedure, then turn that procedure into a reusable artifact.

A practical Skill structure

Open WebUI's documentation recommends a structured approach. A practical Skill can look like this:

my-project/
└── .agents/
    └── skills/
        └── django-production-debug/
            └── SKILL.md

A strong SKILL.md should normally contain sections such as:

1. When to Use — concrete trigger phrases and conditions.
2. Prerequisites — environment variables, credentials, services or required tools.
3. How to Run — the canonical workflow.
4. Quick Reference — important commands, routes, files or APIs.
5. Procedure — numbered, deterministic steps.
6. Pitfalls — known failure modes and limits.
7. Verification — a focused test proving that the workflow succeeded.

For complex Skills, keep the main file scannable and move large reference material or scripts into supporting directories. This prevents the Skill itself from becoming an enormous block of instructions.

Skills plus Open Terminal: where the system becomes useful

Skills become substantially more powerful when paired with a terminal tool.

Think of the division this way:

This separation is important for security. A Skill should not be treated as an authorization mechanism. An instruction file saying “run this command” does not magically grant the agent permission to run it. Tool configuration, access control, terminal identity and the surrounding environment still determine what the agent can actually do.

Terminal Skills and project-local workflows

Open WebUI 0.11.4 can surface Skills supplied by a connected terminal alongside workspace Skills. This opens an interesting model for development teams: the reusable workflow can live next to the codebase instead of being locked inside one UI installation.

For example:

.agents/
└── skills/
    ├── run-django-tests/
    │   └── SKILL.md
    ├── review-api-change/
    │   └── SKILL.md
    └── deploy-staging/
        ├── SKILL.md
        └── references/
            └── staging-checklist.md

A developer can then work with the same repository-specific Skill conventions across compatible agent environments that understand the Agent Skills layout. This also makes Skills easier to version-control and review as code.

Skills versus AGENTS.md: use both, but for different jobs

It is tempting to put everything into AGENTS.md. That usually produces a large instruction file that mixes permanent project rules with task-specific procedures.

For example, “Never commit secrets” belongs naturally in project instructions. “When a Django migration fails in staging, perform these six diagnostic checks and verify the database state before retrying” is a better Skill.

How to verify that a Skill actually works

Do not consider a Skill finished because Open WebUI created the file. Test it like a small piece of operational documentation.

Verification checklist

1. Start a new chat with the intended model and terminal selected.
2. Confirm the Skill appears in the available Skills interface or manifest when applicable.
3. Trigger the workflow using the language you expect users to use.
4. Check that the model follows the intended sequence rather than improvising a completely different procedure.
5. Verify that required tools are actually available.
6. Confirm the final state with a concrete test, not merely a successful-looking response.
7. Try one expected failure case and make sure the Skill handles it safely.

For a deployment Skill, for example, verification could be a health endpoint check plus service status rather than “the command returned without an error.”

Why Skills sometimes appear to be broken

The model knows the Skill exists but does not use it

Check whether native function calling and built-in tools are enabled. Open WebUI's documentation notes that automatic manifest discovery and the view_skill mechanism depend on that setup. If those capabilities are unavailable, selected or bound Skills may be injected differently.

The Skill works when selected manually but not automatically

Improve the Skill's name and description. The description should contain the task vocabulary that a model would encounter in a real request. “Production deployment” is less useful than “Deploy a Django application with Gunicorn and Nginx to staging, including migration and health checks.”

The Skill is available but the terminal workflow fails

Separate instruction failure from tool failure. First verify the terminal connection and permissions. Then run the underlying command manually. A Skill cannot repair a missing binary, broken credential, unavailable network route or denied filesystem permission merely by describing the desired action.

Changes to a Skill seem to be ignored

Start a fresh turn or chat and check which Skill version is actually being loaded. Also remember that lazy loading means the model may only load the full Skill when it decides it is relevant.

A terminal Skill disappears after switching terminals

This can be expected. Open WebUI's release notes say terminal Skills follow the selected terminal and are cleared when the terminal selection changes. Verify that the desired terminal is selected before debugging the Skill itself.

Security: Skills are instructions, not a trust boundary

This is the part that deserves more attention than most Skills tutorials give it.

A Skill can contain instructions that influence an agent's behavior. If that agent also has shell, filesystem, network, Git, browser or other tools, the consequences of a malicious or badly written Skill can become much larger than the Markdown file suggests.

Use the following rules:

• Review imported Skills before enabling them. Treat third-party Skill repositories as code-adjacent configuration, not harmless prompts.
• Keep permissions narrower than the workflow requires. A deployment Skill should not automatically need unrestricted access to every directory on the machine.
• Do not put secrets in Skills. Use the environment's credential mechanisms rather than hard-coding API keys, passwords or tokens into SKILL.md.
• Do not treat Skill text as authorization. A Skill can request an operation; it should not be the thing that decides whether the operation is permitted.
• Version-control project Skills. Review changes like other operational configuration.
• Separate destructive operations. Database deletion, force pushes, credential rotation and production shutdowns should have explicit safeguards.

Open WebUI also documents access controls for Skills. New Skills are private by default, and sharing can be granted to users or groups. Binding a Skill to a model does not bypass those access controls; users still need access to the Skill.

Performance and context trade-offs

Skills solve a context-management problem, but they do not make context free.

A direct $ mention injects the Skill's full instructions. If the Skill is very large, that consumes context that could otherwise hold conversation history or retrieved project information.

Lazy loading is more efficient for larger collections because the model can first see the Skill's name and description and retrieve the full instructions only when needed. That makes concise descriptions especially important.

For most practical projects, a good pattern is:

1. Keep the Skill's main procedure concise.
2. Move detailed reference material into references/.
3. Keep scripts in scripts/ rather than embedding huge shell blocks.
4. Use explicit verification steps.
5. Remove duplicated background information that the model can obtain from the project itself.

Open WebUI Skills compared with the broader Agent Skills ecosystem

The interesting development is that Skills are no longer limited to one application. Open WebUI documents compatibility with the Agent Skills format, while other agent projects are also adopting directory-based SKILL.md workflows.

That creates an opportunity: instead of writing a different prompt for every coding agent, you can maintain reusable task instructions in a project-local Skill directory and use compatible agents where their implementations support the same conventions.

Compatibility is not automatic, however. Two systems may both understand SKILL.md but differ in discovery, permissions, tool names, supported frontmatter, resource loading and execution environment. Always check the target agent's documentation before assuming a Skill is portable.

Recommended workflow for building a serious Skill library

1. Find a repeated task. Do not create Skills for every imaginable prompt.
2. Perform the task successfully once. Capture the commands, decisions and verification checks.
3. Create the Skill. Use Open WebUI's editor or /skills:create.
4. Make the trigger specific. Describe exactly when the Skill should be considered.
5. Remove secrets and machine-specific assumptions.
6. Add failure handling. Document what to inspect when the happy path fails.
7. Add verification. Define one or more observable success conditions.
8. Test on a clean conversation. This catches accidental dependence on previous chat context.
9. Review permissions. Make sure the tools available to the agent match the actual risk.
10. Version and maintain it. Treat changes to production-facing Skills like changes to operational documentation or code.

Useful Open WebUI Skill commands and paths

Frequently asked questions

Are Open WebUI Skills the same as tools?

No. Skills are instruction sets. Tools provide executable capabilities. A Skill can teach a model how to use a terminal tool, but the Skill itself is not a replacement for that tool.

Can I create a Skill without writing Markdown manually?

Yes. Open WebUI 0.11.4 introduced /skills:create, which can turn a completed chat workflow into a reusable Skill when a terminal is selected.

Where does a Skill created from chat go?

Open WebUI documents the generated project Skill at the selected terminal's .agents/skills/<skill-name>/SKILL.md, with supporting resources placed alongside it when needed.

Do Skills automatically get access to my server?

No. Skill instructions do not themselves grant operating-system permissions. What an agent can actually do depends on the tools and permissions configured around it.

Why should I keep the Skill description short and precise?

Because the description can be used as part of the Skill's lightweight discovery manifest. A precise description gives the model a better signal for deciding when the full Skill should be loaded.

Can I share Skills with other Open WebUI users?

Yes. Open WebUI documents access control and sharing for Skills, including user and group access. New Skills are private by default.

Can the same Skill work in other coding agents?

Often, if the other agent supports the Agent Skills format, but compatibility should be verified. Tool names, permissions, discovery and resource handling can differ between implementations.

Official sources

• Open WebUI Skills documentation
• Open WebUI v0.11.4 release notes
• Open WebUI GitHub repository

Related GyanAangan guides

• Open WebUI Skills Not Loading: Open Terminal Compatibility and 404 Fixes
• Ollama Security in 2026: Model Safety, Network Exposure and Agent Hardening
• LM Studio Bionic MCP Servers: Setup, Tools and Security
• MCP Inspector 2.8.0: Debug Local AI MCP Servers
• projectmem in 2026: Persistent Memory for Local Coding Agents

Bottom line: Open WebUI's current Skills system is most useful when you stop thinking of Skills as saved prompts and start treating them as versioned, testable workflow documentation for agents. The new chat-to-Skill workflow makes that transition much easier: solve a task, capture the reliable procedure, verify it, then reuse it instead of rebuilding the same instructions every time.