Ein Skill weiß nichts: Markenwissen als OKF-Bundle statt als Dateihaufen im Chat

Ein neuer Freelancer fängt bei Ihnen an. Bis seine Texte nach Ihrer Marke klingen, vergehen Wochen, Korrekturschleife um Korrekturschleife. Mit einem Sprachmodell läuft dieselbe Geschichte ab, nur schneller und öfter: Sie kippen bei jeder Aufgabe wieder dieselben Dateien in den Chat, Styleguide, Tonalitätsregeln, drei Beispieltexte, eine alte Präsentation, und hoffen, dass diesmal das Richtige hängen bleibt.

Dagegen hilft kein besserer Prompt. Es fehlt ein Ort.

Seit Juni 2026 gibt es für diesen Ort ein Format. Ich habe mein GEO-Wissen darin abgelegt und arbeite seither anders. Dieses Bundle zeige ich Ihnen hier vollständig, Datei für Datei, und stelle es am Ende unter CC BY 4.0 zum Download.

Warum ein besserer Prompt das Problem nicht löst

Das Kontextfenster ist endlich, und je voller es wird, desto schlechter arbeitet das Modell – ich habe das an anderer Stelle an konkreten Token-Grenzen durchgerechnet. Wer bei jeder Aufgabe fünf Dateien aus drei Quellen nachschiebt, bezahlt zweimal. Einmal in Tokens. Einmal in Qualität, weil das Modell in einem überladenen Fenster anfängt, Details zu vergessen oder zu erfinden.

Der zweite Denkfehler steckt tiefer. Die Frage bei KI-Instruktionen lautet nicht „was schreibe ich“, sondern „wohin gehört es“. Sechs Zonen habe ich dort beschrieben, von den Produkt-Einstellungen bis zum einmaligen Prompt. Eine fehlte: das Wissen selbst. Denn Wissen ist keine Anweisung. Ihr Markenversprechen, Ihre Zielgruppendefinition, der dokumentierte Ablauf eines Audits – das gehört weder in eine Einstellung noch in einen Prompt. Das gehört in eine Ablage, auf die jede Anweisung zeigen kann.

Genau hier setzt das Open Knowledge Format an, kurz OKF.

Was das Open Knowledge Format festlegt – und was bewusst nicht

OKF ist ein Verzeichnis aus Markdown-Dateien mit YAML-Frontmatter. Das ist die ganze Idee. Google Cloud hat die Spezifikation in der Version 0.1 seit Juni 2026 im Repository GoogleCloudPlatform/knowledge-catalog offen liegen, unter Apache-2.0-Lizenz. Kein SDK, kein Konto, kein Dienst dahinter. Wer eine Datei öffnen kann, liest OKF; wer ein Repo klonen kann, liefert es aus.

Ein OKF-Bundle ist für ein Sprachmodell das, was eine eingerichtete Werkstatt für einen Handwerker ist: Werkzeug und Nachschlagewerke stehen sortiert an ihrem Platz, und wer neu anfängt, findet sich in einer halben Stunde zurecht. Anders als in der Werkstatt greift das Modell aber nicht selbst ins Regal. Es liest zuerst das Inhaltsverzeichnis und holt danach genau die zwei Dateien, die die Aufgabe braucht. Die Spezifikation nennt das progressive Offenlegung.

Bemerkenswert an dem Dokument ist, wie wenig es vorschreibt. Verpflichtend ist ein einziges Feld: type. Eine kurze Zeichenkette, die sagt, um welche Art von Wissen es sich handelt, Methode etwa oder Playbook. Welche Typen es gibt, legt niemand zentral fest. Empfohlen, aber nicht erzwungen sind title, description, resource, tags und timestamp.

Zwei Dateinamen sind reserviert. Die index.md listet auf, was im Verzeichnis liegt. Die log.md führt die Änderungshistorie, nach ISO-Datum gruppiert, neueste zuerst. Alles andere im Baum ist ein Konzept, also eine Wissenseinheit, eine Datei. Konzepte verlinken sich mit normalen Markdown-Links gegenseitig. Die Spezifikation empfiehlt die absolute Form ab der Bundle-Wurzel (/methoden/chunking.md), weil sie stabil bleibt, wenn Dateien innerhalb ihres Verzeichnisses verschoben werden.

Die Konsumregeln sind der eigentliche Trick. Ein Bundle darf nicht abgelehnt werden, weil optionale Felder fehlen, ein type unbekannt ist oder ein Querlink ins Leere zeigt. Ein toter Link ist laut Spezifikation kein Fehler; er markiert Wissen, das noch niemand geschrieben hat. Das klingt nach einer Kleinigkeit und ist der Grund, warum das Format im Alltag hält: Ihr Bundle wächst, wird umgebaut, teilweise von Modellen gepflegt, und bleibt trotzdem lesbar.

Was OKF ausdrücklich nicht will, steht ebenso klar drin. Keine feste Taxonomie von Wissenstypen. Keine Vorgaben zu Speicherung oder Abfrage. Kein Ersatz für Fachschemata. Ein Format, keine Plattform.

Neu ist das Muster nicht. Andrej Karpathy hat es am 4. April 2026 als „LLM Wiki“ beschrieben, inzwischen über 5.000-mal auf GitHub markiert: Statt bei jeder Frage aus Rohdokumenten neu zu synthetisieren, pflegt das Modell ein dauerhaftes, verlinktes Markdown-Wiki, das mit jeder Quelle reicher wird. Sein Bild dafür ist griffig: Obsidian ist die Entwicklungsumgebung, die LLM der Programmierer, das Wiki der Quellcode. Jeder baute dieses Wiki bisher anders. OKF legt die Konventionen fest, an denen sich fremde Bundles und fremde Agenten treffen.

Mein Bundle für die LLM-Content-Erstellung, Datei für Datei

Genug Theorie. So sieht meine Werkstatt aus.

okf-llm-content-erstellung/
├── index.md                 # Einstieg, Metadaten, Pflegeregel
├── log.md                   # Änderungshistorie
├── LICENSE.md
├── methoden/                # redaktionelle Regeln
│   ├── index.md
│   ├── chunking.md
│   ├── sprache-formulierung.md
│   ├── zitierwuerdigkeit.md
│   ├── query-fan-out.md
│   ├── aktualitaet.md
│   └── eeat-autorschaft.md
├── technik/                 # Crawler-Zugang, semantisches HTML
├── offpage/                 # Mentions und Grounding
├── messung/                 # Share of Mentions
├── playbooks/               # Seiten-Umbau, URL-Priorisierung
├── beispiele/               # Vorher-Nachher-Praxisfall
├── vorlagen/                # Seitenstruktur, FAQ-Block, Update-Box
├── quellen/                 # fünf verdichtete Quellkonzepte
└── referenz/                # Glossar, Anti-Patterns

In Zahlen: 35 Markdown-Dateien in neun Verzeichnissen, davon 24 Konzepte, zehn Index-Dateien und ein Log. Rund 6.000 Wörter, 129 interne Querverweise, 40 Kilobyte als ZIP. Ein Bundle ist klein. Das ist der Punkt.

Die Wurzel-index.md ist die einzige Datei, in der die Spezifikation Frontmatter im Index erlaubt, nämlich zur Versionsangabe. Meine sieht so aus:

---
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 steht in der Spezifikation, der Rest sind meine eigenen Felder. Erlaubt: Produzenten dürfen beliebige Schlüssel ergänzen, Konsumenten müssen sie tolerieren.

Darunter folgt die Auflistung nach Bereichen, jeder Eintrag mit der Beschreibung aus dem Frontmatter der verlinkten Datei. Ein Modell liest diese eine Datei und weiß, was es im Haus gibt, ohne 6.000 Wörter zu laden.

Ein Konzept sieht dann so aus. Auszug aus 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)

Drei Details in dieser Datei tragen die ganze Konstruktion.

Der Abschnitt „Grenzen der Methode“ ist mir der wichtigste. Ohne ihn schreibt das Modell meine Regeln als Naturgesetze fort, und ich lese im Kundentext plötzlich, semantisches Chunking sei ein Standard mit definierter Länge. Ist es nicht. Wer die Grenze nicht dokumentiert, bekommt sie als Halluzination zurück.

Und hier die offene Baustelle, die Sie ohnehin sehen, sobald Sie das ZIP öffnen: In meinem Bundle steht so ein Abschnitt erst in fünf von 24 Konzepten, verteilt auf vier verschiedene Überschriften – „Grenzen der Methode“, „Risiken und blinde Flecken“, „Abgrenzung“, „Einordnung“. Genau das ist der Zustand, in dem die meisten Wissensbasen ihr erstes Jahr verbringen. Er steht auf meiner Pflegeliste. Machen Sie es von Beginn an sauberer als ich: eine Überschrift, jedes Konzept.

Der # Citations-Block zeigt auf /quellen/, nicht ins Web. Fünf Quellkonzepte liegen dort, jedes in eigenen Worten verdichtet, jedes mit einer Verlässlichkeitseinschätzung. Beim Aufbau habe ich aus dem Rohmaterial die Marketing-6.0-Rahmung und die inhaltstypspezifischen Token-Tabellen verworfen, weil sie nicht belegt waren, und nur Entity-First und Self-Containment übernommen. Diese Entscheidung steht im Log. In sechs Monaten weiß ich noch, warum.

Und die Querverweise – 129 im Bundle – machen aus dem Ordner einen Graphen. Frage ich nach Chunking, findet das Modell von dort aus den Weg zu Query-Fan-out, zur Messung und zum Glossar, ohne dass ich die Dateien benenne.

Die Pflegeregel steht in der Wurzel und ist bewusst stumpf: Ein Konzept gilt als überprüfungsbedürftig, wenn sein timestamp älter als sechs Monate ist oder eine zitierte Quelle sich substanziell geändert hat. Kurator bin ich. Modelle pflegen nur auf Freigabe.

Der Handwerker und die Werkstatt

Jetzt die Unterscheidung, um die es mir eigentlich geht.

Ein Skill ist ein Ausführender. Er kennt einen Ablauf: Erstens dies, zweitens jenes, am Ende liegt ein Angebot oder ein Audit auf dem Tisch. Was ein Skill nicht hat, ist Wissen. Er weiß nichts über Ihre Marke, Ihre Kunden, Ihre Fehler aus dem letzten Quartal. Er ist der Handwerker, der zur Tür hereinkommt.

Das Bundle ist die Werkstatt. Es führt nichts aus. Es ist der Ort, an dem steht, was wahr ist.

Trennt man beides, hört ein Ärgernis auf: Man muss dasselbe Wissen nicht mehr in jeden Skill kopieren und dann in fünf Skills gleichzeitig aktualisieren. Der Skill sagt, in welcher Reihenfolge gearbeitet wird, und zeigt für alles Inhaltliche auf das Bundle. Ändert sich meine Chunking-Regel, ändere ich eine Datei.

Der praktische Gewinn zeigt sich beim Onboarding. Kommt ein Freelancer oder eine Agentur dazu, bekommen sie Zugriff auf den Ordner und den Pfad. Eine halbe Stunde später arbeitet das Modell, mit dem sie ohnehin arbeiten, in der Markenstimme. Kein Format-Umbau, kein Export, kein Zugang zu meinem Werkzeug. Wechsle ich von Claude zu ChatGPT oder zu etwas, das es 2027 noch nicht gibt, zeige ich auf denselben Ordner. Markdown versteht jedes Modell.

So bauen Sie Ihr eigenes Bundle

Fünf Schritte. Rechnen Sie mit zwei bis drei Tagen für die erste brauchbare Fassung, nicht mit einem Nachmittag.

Schritt 1: Bereiche schneiden. Legen Sie einen Ordner an und darin drei bis sieben Unterverzeichnisse entlang Ihrer Arbeit, nicht entlang Ihres Org-Charts. Ergebnis: Sie können jeden Bereich in einem Satz beschreiben. Häufigster Fehler: Verzeichnisse nach Abteilungen schneiden. Dann liegt dasselbe Wissen dreimal im Baum.

Schritt 2: Ein Konzept, eine Datei. Jede Datei bekommt Frontmatter mit type, title, description und timestamp sowie einen Abschnitt zu den Grenzen. Ergebnis: Jede Datei ist ohne die anderen verständlich. Fehlerbild: Sammeldateien namens sonstiges.md. Was dort landet, findet das Modell nie wieder.

Schritt 3: Index schreiben. Pro Verzeichnis eine index.md ohne Frontmatter, die jeden Eintrag mit der Beschreibung aus dessen Frontmatter auflistet. Ergebnis: Das Modell kennt nach einer Datei den ganzen Bereich. Fehlerbild: Der Index veraltet, weil ihn niemand mitzieht. Lassen Sie ihn generieren.

Schritt 4: Verlinken und belegen. Setzen Sie absolute Links ab der Bundle-Wurzel (/methoden/chunking.md) und legen Sie unter # Citations ab, worauf eine Behauptung fußt. Ergebnis: Ein Klickpfad von jeder Aussage zu ihrer Herkunft. Fehlerbild: relative Links, die beim ersten Umbau brechen.

Schritt 5: Log führen und dann erst automatisieren. Jede Änderung mit ISO-Datum in die log.md, inklusive der Dinge, die Sie bewusst nicht übernommen haben. Ergebnis: In sechs Monaten ist jede Entscheidung nachvollziehbar. Erst danach setzen Sie einen Skill obendrauf, der das Bundle liest.

Wann sich das lohnt – und wann nicht

Ein Bundle rechnet sich, wenn dasselbe Wissen wiederholt in dieselben Aufgaben fließt, wenn mehrere Menschen darauf zugreifen, oder wenn Sie zwischen Modellen und Werkzeugen wechseln. Schreiben Sie zwei Texte im Monat allein und in einem Werkzeug, reicht eine Projektanweisung. Der Ordner wäre dann Verwaltung ohne Gegenwert.

Drei Stolperstellen sollten Sie kennen, bevor Sie anfangen.

Veraltetes Wissen ist schlimmer als keines. Ein Bundle wirkt autoritativ, gerade auf ein Modell. Steht dort eine Regel von vor zwei Jahren, produziert es diese Regel überzeugt und ausführlich. Ohne Pflegeintervall lassen Sie es besser bleiben.

Ein Ordner kennt keine Rechte. Es gibt keine Zugriffskontrolle, keine Verschlüsselung, keine Rollen. Kundendaten, Preise, Zugänge haben in einem Bundle nichts verloren, das Sie weitergeben. Meine Freigabe-Gates und alles Kundenspezifische lagen deshalb nie drin.

Und die Version steht auf 0.1, ausdrücklich als Entwurf. Kleinere Versionssprünge bleiben abwärtskompatibel, ein großer darf Pflichtfelder umbenennen. Bei einem Ordner Markdown ist das Migrationsrisiko überschaubar – aber es ist nicht null.

Das Bundle zum Download

Hier ist meine Werkstatt, komplett und ungekürzt.

okf-llm-content-erstellung-v1.2.0.zip – 40 KB, 35 Markdown-Dateien, OKF v0.1

Wer lieber versioniert mitliest oder das Bundle forken will, findet es auch als Repository auf GitHub: github.com/eullr/okf-llm-content-erstellung.

Entpacken, den Ordner dorthin legen, wo Ihr Modell Dateizugriff hat, und im Prompt auf die index.md zeigen. Mehr Installation gibt es nicht.

Lizenz: CC BY 4.0. Sie dürfen das Bundle kopieren, verändern, in eigene Bundles einbauen und kommerziell einsetzen, auch in Kundenprojekten. Die einzige Bedingung ist die Namensnennung:

Basiert auf dem Bundle „LLM-Content-Erstellung“ von Eugen Ullrich (eullrich.com), lizenziert unter CC BY 4.0. Geändert am [Datum].

Die Bedingungen liegen als LICENSE.md im Bundle, der Lizenz-Volltext ist von dort verlinkt. Gewährleistung gibt es keine: Das Bundle beschreibt den Stand meiner Praxis zum timestamp des jeweiligen Konzepts. Generative Systeme ändern ihr Verhalten laufend. Prüfen Sie jede Methode gegen Ihre eigene Messung, bevor Sie sie auf ein Kundenprojekt loslassen – und verlassen Sie sich nicht darauf, dass jedes Konzept seine Grenzen schon dokumentiert hat.

Die Werkstatt bleibt stehen

Am Anfang stand der Freelancer, der Wochen braucht, bis er nach Ihrer Marke klingt. Das Problem war nie sein Talent und nie die Länge Ihres Prompts. Es war die fehlende Ablage.

Machen Sie den Test an einer einzigen Datei. Nehmen Sie die Regel, die Sie in diesem Monat am häufigsten in einen Chat getippt haben, schreiben Sie sie in eine Markdown-Datei mit type, title und timestamp, hängen Sie einen Abschnitt „Grenzen“ an und zeigen Sie beim nächsten Mal darauf. Das ist Ihr Bundle, Version 0.1. Der Rest ist Ausbau.

Häufige Fragen

Was ist der Unterschied zwischen einem OKF-Bundle und einer CLAUDE.md oder AGENTS.md?

Eine CLAUDE.md ist eine Anweisungsdatei: Sie sagt einem Agenten, wie er sich verhalten soll, und wird bei jeder Sitzung vollständig geladen. Ein OKF-Bundle ist eine Wissensablage, aus der das Modell über den Index gezielt einzelne Dateien holt. Beides ergänzt sich: Die CLAUDE.md bleibt kurz und verweist auf das Bundle, statt das Wissen selbst zu enthalten.

Braucht man für OKF ein Google-Cloud-Konto oder ein bestimmtes Tool?

Nein. OKF ist eine Spezifikation, kein Dienst. Die Spezifikation und die Referenz-Implementierungen stehen unter Apache-2.0 im Repository GoogleCloudPlatform/knowledge-catalog. Sie brauchen einen Ordner, einen Texteditor und ein Modell mit Dateizugriff. Kein Konto, kein SDK, keine Bindung an einen Anbieter.

Wie groß darf ein Bundle werden, bevor das Kontextfenster wieder überläuft?

Die Größe des Bundles ist nicht das Limit, weil das Modell nie alles lädt. Es liest die index.md und holt danach die passenden Konzepte. Mein Bundle hat rund 6.000 Wörter, geladen werden pro Aufgabe meist zwei bis drei Dateien. Entscheidend ist deshalb die Qualität der Index-Dateien, nicht der Umfang des Bundles.

Lohnt sich ein Bundle für eine Ein-Personen-Marke?

Wenn Sie regelmäßig Inhalte produzieren und dabei zwischen Werkzeugen wechseln: ja. Der Nutzen entsteht bei der Wiederholung, nicht bei der Teamgröße. Bei zwei Texten im Monat in einem einzigen Werkzeug reicht eine Projektanweisung.

Muss ich mein Bundle veröffentlichen?

Nein. Das Feld visibility im Root-Index ist mein eigenes, kein Bestandteil der Spezifikation. Die meisten Bundles bleiben intern. Ich veröffentliche dieses, weil geteiltes Methodenwissen mir mehr nützt, als es mir schadet – die Arbeit steckt in der Anwendung auf ein konkretes Projekt, nicht in der Regel selbst.