An instruction package is a saved file that carries your rules, style, and workflow steps so you stop re-typing them every session. Hosted tools call these "skills"; on a local stack you build them yourself — an Ollama Modelfile bakes a system prompt into a named model you can call like any other, and Open WebUI custom agents wrap the same file with tools and knowledge. Same pattern, your machine, zero recurring cost. :::

What the Pattern Actually Is

Strip away the branding and every "skills" system is three parts:

1. A trigger — how the system decides these instructions are relevant now. Claude reads a description field; you might just invoke the package by name.
2. A lean instruction core — the standing orders: voice, format, steps, constraints.
3. A progressive-disclosure tail — scripts and long reference documents the model only opens when needed, so the core stays small.

That structure is worth copying because it fixes the two failure modes of ad-hoc prompting. Vague, re-typed prompts drift — the tenth "write this like last time" is not the first. And stuffing everything into one giant system prompt wastes context on instructions that only matter sometimes.

Port 1: The Ollama Modelfile — Skills Baked Into the Model

Ollama lets you create a named model from a base model plus a Modelfile. The SYSTEM block is your instruction core. The name is your trigger — you don't describe the skill, you just call it.

Say you summarize customer support tickets the same way every week. Write the standing orders once:

# Modelfile — ticket-summarizer
FROM qwen2.5:14b

SYSTEM """
You summarize support tickets for a fintech operations team.
Rules:
- Open with a one-line verdict: bug, user error, or account issue.
- List affected product areas as bullet points.
- Quote at most one sentence from the customer, verbatim.
- Close with suggested next action for the on-call engineer.
- Never speculate about causes beyond what the ticket states.
- Tone: plain, direct, no hedging.
"""

Build it and the skill becomes a model you invoke by name:

ollama create ticket-summarizer -f Modelfile
ollama run ticket-summarizer "Ticket #4821: payment stuck on pending..."

To anyone scripting against this, ticket-summarizer is just another model. That's the quiet superpower: an n8n workflow or a shell script can call your "skill" with zero prompt engineering inside the automation — the instructions ship inside the artifact.

{
  "model": "ticket-summarizer",
  "messages": [{ "role": "user", "content": "{{ $json.ticketBody }}" }]
}

That JSON is the entire body of an n8n HTTP Request node pointing at http://localhost:11434/api/chat. The workflow never contains the rules; it just routes work to the model that has them.

Port 2: Open WebUI Custom Agents — Skills With a Knowledge Tail

A Modelfile is all standing orders, no reference material. When your skill needs documents — a product catalog, a style guide, past examples — Open WebUI's custom agents are the better port. Each agent is a saved persona: a system prompt, a set of knowledge files, and optionally tools like web search.

The structure maps directly onto the skills anatomy:

• Trigger — the agent's name in a dropdown, or @agent-name mentioned in a chat.
• Instruction core — the agent's system prompt, kept lean on purpose.
• Progressive tail — knowledge files the agent retrieves from only when a question touches them, plus RAG over your documents.

The discipline that makes hosted skills work applies identically here: put the how in the prompt and the what in the files. "Summarize using this five-step format" is prompt. A forty-page refund policy document is a knowledge file.

Writing the Instruction Core So It Actually Fires

Whether the core lands in a SKILL.md, a SYSTEM block, or an agent prompt, the same writing rules decide if it works:

• Explain the why, not just the rule. "Quote at most one sentence — full quotes bury the verdict" survives edge cases better than "quote one sentence."
• Imperative steps, numbered. The model follows sequences better than essays. 1. Classify. 2. Extract. 3. Recommend.
• Ship one good/bad example pair. Nothing steers output like a concrete before/after. One example outperforms three paragraphs of adjectives.
• End with a validation step. "Before answering, confirm the response has: verdict, areas, quote, action." Models genuinely catch their own omissions when asked to check.
• Keep the core under ~500 words. If it grows, that's a sign the overflow belongs in a reference file or knowledge document.

Versioning: The Part Hosted Platforms Can't Give You

Here's the local-stack advantage that's easy to miss. An instruction package that lives in a text file is a versioned artifact:

git init ~/skills && cd ~/skills
git add ticket-summarizer/Modelfile
git commit -m "ticket-summarizer v2: add verdict line, cap quote at 1 sentence"
ollama create ticket-summarizer -f ticket-summarizer/Modelfile

When the output drifts or a rule turns out wrong, you don't reverse-engineer what you told the model three weeks ago — you git diff it. Rollback is git checkout. Team sharing is a repo, not a plan tier. The skill stops being a setting inside someone else's app and becomes software you maintain like software.

A minimal repo layout:

~/skills/
├── ticket-summarizer/
│   ├── Modelfile
│   └── examples.md        # good/bad pairs the prompt references
├── brand-voice/
│   └── Modelfile
└── weekly-report/
    ├── Modelfile
    └── reference/
        └── metric-definitions.md

When to Use Which Port

In practice the two local ports compose. The Modelfile carries procedures your n8n workflows call at 3 a.m.; the agent carries the searchable knowledge your team pokes at during the day. Same pattern, two deployment shapes.

Common Failure Modes and Fixes

• The skill never triggers. On hosted platforms, that's a vague description — add keywords and explicit if/then scenarios. Locally, it's usually calling the base model name instead of your custom one. ollama list is your ground truth.
• Output inconsistent across runs. The core is too thin. Add the example pair and the validation step; both are single edits with outsized effect.
• Prompt grows until quality drops. Move stable reference material out of the core into examples.md or a knowledge file. Lean cores, fat tails.
• Scripts don't run. Hosted skills need code execution enabled; local stacks need the tool wired into the agent. In both cases the failure is configuration, not the model.

Frequently Asked Questions

Does a Modelfile actually retrain the model?

No. It wraps a base model with a persistent system prompt, generation parameters, and optionally a template. Weights are untouched — that's why creation takes seconds and why you can delete the custom model without affecting the base. It behaves like training because the instructions are always present, mechanically.

Can local instruction packages really match hosted skills?

For the core pattern — define once, trigger reliably, references on demand — yes, with more manual wiring. Hosted platforms add polish: auto-triggering descriptions, sharing menus, managed execution. If you need the pattern inside automations you control, the local port is often simpler, because a named model is an API-native building block.

How many instruction packages should I maintain?

Start with two or three that remove real daily friction — a summarizer, a brand voice, a report writer. Each additional package costs maintenance: when a rule changes, every package carrying it must change. Fewer, well-versioned packages beat a folder of stale ones.

Do instruction files consume context every single call?

Yes — the core prompt rides along on every request, which is exactly why it should stay lean. The progressive-disclosure habit exists to protect you here: only the standing orders travel constantly; the fifty pages of reference material stay on disk until a question needs them.

The daily briefing of the amnesiac intern is a choice, not a fact of AI life. Write the standing orders once, name them, version them, and point your automations at the name. Whether the folder is called a skill or a Modelfile, the win is the same: you stop prompting and start operating.