A skill knows nothing: brand knowledge as an OKF bundle instead of a pile of files in the chat
A new freelancer starts with you. Until their texts sound like your brand, weeks pass, correction loop after correction loop. With a language model the same story plays out, only faster and more often: for every task you dump the same files into the chat again, style guide, tonality rules, three example texts, an old presentation, and hope that this time the right thing sticks.
Against this no better prompt helps. A place is missing.
Since June 2026 there is a format for this place. I have stored my GEO knowledge in it and have worked differently ever since. This bundle I show you here in full, file by file, and at the end make it available to download under CC BY 4.0.
Why a better prompt does not solve the problem
The context window is finite, and the fuller it gets, the worse the model works — I have worked this out elsewhere at concrete token limits. Whoever pushes five files from three sources for every task pays twice. Once in tokens. Once in quality, because in an overloaded window the model starts to forget or invent details.
The second fallacy sits deeper. The question with AI instructions is not “what do I write” but “where does it belong”. Six zones I described there, from the product settings to the one-off prompt. One was missing: the knowledge itself. Because knowledge is not an instruction. Your brand promise, your audience definition, the documented process of an audit — that belongs neither in a setting nor in a prompt. That belongs in a store any instruction can point to.
Exactly here the Open Knowledge Format sets in, OKF for short.
What the Open Knowledge Format defines — and what deliberately not
OKF is a directory of Markdown files with YAML frontmatter. That is the whole idea. Google Cloud has had the specification in version 0.1 openly available since June 2026 in the repository GoogleCloudPlatform/knowledge-catalog, under an Apache-2.0 license. No SDK, no account, no service behind it. Whoever can open a file reads OKF; whoever can clone a repo serves it.
An OKF bundle is to a language model what a set-up workshop is to a craftsman: tools and reference works stand sorted in their place, and whoever starts fresh finds their way in half an hour. Unlike in the workshop, though, the model does not reach into the shelf itself. It first reads the table of contents and then fetches exactly the two files the task needs. The specification calls that progressive disclosure.
Remarkable about the document is how little it prescribes. Mandatory is a single field: type. A short string that says what kind of knowledge it is, Methode say, or Playbook. Which types exist no one sets centrally. Recommended but not enforced are title, description, resource, tags and timestamp.
Two file names are reserved. The index.md lists what lies in the directory. The log.md keeps the change history, grouped by ISO date, newest first. Everything else in the tree is a concept, that is a unit of knowledge, one file. Concepts link to one another with normal Markdown links. The specification recommends the absolute form from the bundle root (/methoden/chunking.md), because it stays stable when files are moved within their directory.
The consumption rules are the actual trick. A bundle may not be rejected because optional fields are missing, a type is unknown or a cross-link points into the void. A dead link is, per the specification, not an error; it marks knowledge no one has written yet. That sounds like a trifle and is the reason the format holds in everyday use: your bundle grows, gets rebuilt, is partly maintained by models, and stays readable nonetheless.
What OKF explicitly does not want stands just as clearly in it. No fixed taxonomy of knowledge types. No specifications on storage or querying. No replacement for domain schemas. A format, not a platform.
The pattern is not new. Andrej Karpathy described it on 4 April 2026 as an “LLM Wiki”, since then marked over 5,000 times on GitHub: instead of synthesizing anew from raw documents for every question, the model maintains a permanent, linked Markdown wiki that grows richer with every source. His image for it is catchy: Obsidian is the development environment, the LLM the programmer, the wiki the source code. Everyone built this wiki differently so far. OKF sets the conventions where foreign bundles and foreign agents meet.
My bundle for LLM content creation, file by file
Enough theory. This is what my workshop looks like.
okf-llm-content-erstellung/
├── index.md # entry, metadata, maintenance rule
├── log.md # change history
├── LICENSE.md
├── methoden/ # editorial rules
│ ├── index.md
│ ├── chunking.md
│ ├── sprache-formulierung.md
│ ├── zitierwuerdigkeit.md
│ ├── query-fan-out.md
│ ├── aktualitaet.md
│ └── eeat-autorschaft.md
├── technik/ # crawler access, semantic HTML
├── offpage/ # mentions and grounding
├── messung/ # share of mentions
├── playbooks/ # page rebuild, URL prioritization
├── beispiele/ # before-after practical case
├── vorlagen/ # page structure, FAQ block, update box
├── quellen/ # five condensed source concepts
└── referenz/ # glossary, anti-patternsIn numbers: 35 Markdown files in nine directories, of which 24 concepts, ten index files and one log. Around 6,000 words, 129 internal cross-references, 40 kilobytes as a ZIP. A bundle is small. That is the point.
The root index.md is the only file in which the specification allows frontmatter in the index, namely for the version statement. Mine looks like this:
---
okf_version: "0.1"
bundle_version: "1.2.0"
author: Eugen Ullrich
contact: [email protected]
visibility: public
license: CC-BY-4.0
license_url: https://creativecommons.org/licenses/by/4.0/deed.de
attribution: "Eugen Ullrich, eullrich.com"
source: https://eullrich.com/blog/okf-bundle-markenwissen
---okf_version stands in the specification, the rest are my own fields. Allowed: producers may add arbitrary keys, consumers have to tolerate them.
Below it follows the listing by area, each entry with the description from the frontmatter of the linked file. A model reads this one file and knows what is in the house, without loading 6,000 words.
A concept then looks like this. Excerpt from methoden/chunking.md:
---
type: Methode
title: Semantisches Chunking
description: Regeln zur Zerlegung von Inhalten in autonome, extrahierbare Blöcke
für generative Systeme.
tags: [geo, chunking, content-architektur, retrieval]
timestamp: 2026-07-15T09:00:00Z
---
# Warum Chunking?
Generative Systeme analysieren Texte nicht linear von Anfang bis Ende. Sie
zerlegen Seiten in einzelne Sinnblöcke (Chunks), wandeln diese in
Vektor-Embeddings um und wählen für eine Antwort den Block mit der höchsten
semantischen Relevanz zum Prompt. [...]
# Kernregeln
1. **Ein Block, eine Aussage.** Jeder Absatz trägt genau einen Fokus [...]
2. **Umgekehrte Pyramide.** Die Kernaussage steht im ersten Satz [...]
4. **Entity-First.** Pronomen konsequent durch die Kernentität ersetzen:
"Amazon Go" statt "das System" [...]
5. **Fragende Zwischenüberschriften.** Das entspricht der Sprache der
Nutzerprompts und den Teilfragen des
[Query-Fan-out](/methoden/query-fan-out.md).
# Grenzen der Methode
* Es existiert kein Industriestandard für die optimale Chunk-Länge. ChatGPT,
Perplexity und AI Overviews schneiden und bewerten unterschiedlich; die
Optimierung bleibt iterativ und wird über die
[Erfolgsmessung](/messung/share-of-mentions.md) gesteuert.
* Ein zu radikal auf Frage-Antwort-Blöcke reduzierter Text kann menschliche
Leser abstossen. [...]
# Citations
[1] [OKR-Framework für die Chunking-Einführung](/quellen/okr-chunking-framework.md)
[2] [GEO-Content-Anforderungen](/quellen/geo-content-anforderungen.md)
[3] [Technical Guide Semantisches Chunking](/quellen/chunking-technical-guide.md)
(nur Entity-First und Self-Containment)The bundle files are German — the language I create in; the structure is what carries here. Three details in this file carry the whole construction.
The section “Grenzen der Methode” (limits of the method) is the most important to me. Without it the model writes my rules on as laws of nature, and I suddenly read in a client text that semantic chunking is a standard with a defined length. It is not. Whoever does not document the limit gets it back as a hallucination.
And here the open construction site you will see anyway as soon as you open the ZIP: in my bundle such a section stands in only five of 24 concepts so far, spread across four different headings — “Grenzen der Methode,” “Risiken und blinde Flecken,” “Abgrenzung,” “Einordnung.” Exactly that is the state in which most knowledge bases spend their first year. It is on my maintenance list. Do it cleaner than me from the start: one heading, every concept.
The # Citations block points to /quellen/, not into the web. Five source concepts lie there, each condensed in its own words, each with a reliability assessment. In building it I discarded from the raw material the Marketing 6.0 framing and the content-type-specific token tables, because they were not evidenced, and adopted only entity-first and self-containment. This decision stands in the log. In six months I still know why.
And the cross-references — 129 in the bundle — turn the folder into a graph. If I ask about chunking, the model finds its way from there to query fan-out, to measurement and to the glossary, without my naming the files.
The maintenance rule stands in the root and is deliberately blunt: a concept counts as in need of review when its timestamp is older than six months or a cited source has changed substantially. Curator am I. Models maintain only on approval.
The craftsman and the workshop
Now the distinction I am actually after.
A skill is an executor. It knows a process: first this, second that, at the end an offer or an audit lies on the table. What a skill does not have is knowledge. It knows nothing about your brand, your customers, your mistakes from last quarter. It is the craftsman who comes in through the door.
The bundle is the workshop. It executes nothing. It is the place where what is true stands.
Separate the two and one annoyance stops: you no longer have to copy the same knowledge into every skill and then update it in five skills at once. The skill says in which order to work, and points for everything content-related to the bundle. If my chunking rule changes, I change one file.
The practical gain shows in onboarding. If a freelancer or an agency joins, they get access to the folder and the path. Half an hour later the model they work with anyway works in the brand voice. No format conversion, no export, no access to my tooling. If I switch from Claude to ChatGPT or to something that does not yet exist in 2027, I point to the same folder. Markdown every model understands.
How to build your own bundle
Five steps. Reckon on two to three days for the first usable version, not on an afternoon.
Step 1: cut areas. Create a folder and in it three to seven subdirectories along your work, not along your org chart. Result: you can describe every area in one sentence. Most common mistake: cutting directories by departments. Then the same knowledge lies in the tree three times.
Step 2: one concept, one file. Every file gets frontmatter with type, title, description and timestamp, plus a section on the limits. Result: every file is understandable without the others. Failure symptom: catch-all files called sonstiges.md. What lands there the model never finds again.
Step 3: write the index. Per directory one index.md without frontmatter that lists every entry with the description from its frontmatter. Result: after one file the model knows the whole area. Failure symptom: the index ages because no one keeps it up. Have it generated.
Step 4: link and evidence. Set absolute links from the bundle root (/methoden/chunking.md) and deposit under # Citations what a claim rests on. Result: a click path from every statement to its origin. Failure symptom: relative links that break at the first rebuild.
Step 5: keep a log and only then automate. Every change with an ISO date into the log.md, including the things you deliberately did not adopt. Result: in six months every decision is traceable. Only after that do you put a skill on top that reads the bundle.
When this pays off — and when not
A bundle pays off when the same knowledge flows repeatedly into the same tasks, when several people access it, or when you switch between models and tools. If you write two texts a month alone and in one tool, a project instruction suffices. The folder would then be administration without return.
Three stumbling blocks you should know before you start.
Outdated knowledge is worse than none. A bundle acts authoritative, especially on a model. If a rule from two years ago stands there, it produces this rule convinced and in detail. Without a maintenance interval, better leave it.
A folder knows no permissions. There is no access control, no encryption, no roles. Customer data, prices, credentials have no place in a bundle you hand on. My approval gates and everything client-specific therefore never lay in it.
And the version stands at 0.1, explicitly as a draft. Minor version jumps stay backward-compatible, a major one may rename mandatory fields. With a folder of Markdown the migration risk is manageable — but it is not zero.
The bundle to download
Here is my workshop, complete and unabridged.
okf-llm-content-erstellung-v1.2.0.zip – 40 KB, 35 Markdown files, OKF v0.1
Whoever prefers to follow along versioned or wants to fork the bundle finds it also as a repository on GitHub: github.com/eullr/okf-llm-content-erstellung.
Unpack, put the folder where your model has file access, and point to the index.md in the prompt. There is no more installation.
License: CC BY 4.0. You may copy, change, build into your own bundles and use commercially, including in client projects. The only condition is attribution:
Based on the bundle “LLM-Content-Erstellung” by Eugen Ullrich (eullrich.com), licensed under CC BY 4.0. Changed on [date].
The conditions lie as LICENSE.md in the bundle, the full license text is linked from there. There is no warranty: the bundle describes the state of my practice at the timestamp of the respective concept. Generative systems change their behavior continuously. Check every method against your own measurement before you set it loose on a client project — and do not rely on every concept already documenting its limits.
The workshop stays standing
At the start stood the freelancer who needs weeks to sound like your brand. The problem was never their talent and never the length of your prompt. It was the missing store.
Make the test on a single file. Take the rule you typed into a chat most often this month, write it into a Markdown file with type, title and timestamp, attach a “limits” section and point to it next time. That is your bundle, version 0.1. The rest is expansion.
Frequently asked questions
What is the difference between an OKF bundle and a CLAUDE.md or AGENTS.md?
A CLAUDE.md is an instruction file: it tells an agent how to behave and is loaded in full every session. An OKF bundle is a knowledge store from which the model fetches individual files deliberately via the index. Both complement each other: the CLAUDE.md stays short and points to the bundle instead of containing the knowledge itself.
Do you need a Google Cloud account or a particular tool for OKF?
No. OKF is a specification, not a service. The specification and the reference implementations stand under Apache-2.0 in the repository GoogleCloudPlatform/knowledge-catalog. You need a folder, a text editor and a model with file access. No account, no SDK, no tie to a provider.
How large may a bundle grow before the context window overflows again?
The size of the bundle is not the limit, because the model never loads everything. It reads the index.md and then fetches the fitting concepts. My bundle has around 6,000 words; per task usually two or three files are loaded. Decisive is therefore the quality of the index files, not the size of the bundle.
Is a bundle worth it for a one-person brand?
If you regularly produce content and switch between tools in the process: yes. The benefit arises from the repetition, not from team size. For two texts a month in a single tool, a project instruction suffices.
Do I have to publish my bundle?
No. The field visibility in the root index is my own, not part of the specification. Most bundles stay internal. I publish this one because shared method knowledge helps me more than it harms me — the work sits in applying it to a concrete project, not in the rule itself.