Ein Open Knowledge Format mit Draft_ erstellen: der Praxisleitfaden
Ein OKF-Bundle ist nichts weiter als ein Verzeichnis aufgeräumter Markdown-Dateien: genau das, was Draft_ produziert, ohne irgendetwas zu konfigurieren. Warum man seine Wissensbasis in einer Markdown-Textverarbeitung schreibt und sie dann unverändert an einen KI-Agenten übergibt. Drei Fälle, in denen es alles verändert.
Googles Open Knowledge Format (OKF) verlangt kein proprietäres Werkzeug. Ein Bundle ist ein Verzeichnis von Markdown-Dateien, ein wenig YAML-Frontmatter, Links zwischen den Konzepten, und das war’s. Mit anderen Worten: Das Format ist bereits dein Texteditor.
Allerdings sind «möglich» und «angenehm» keine Synonyme. Eine Wissensbasis zu schreiben ist Schreibarbeit: Man will einen ruhigen Ort dafür, kein Terminal. Genau hier passt Draft_, nicht dank einer eigenen «OKF»-Funktion, sondern weil sein natives Format bereits das des OKF ist. Schauen wir, warum, und dann drei konkrete Fälle, in denen es zählt.
Warum eine Markdown-Textverarbeitung für OKF?
OKF trennt zwei Rollen: die, die das Wissen produziert, und die, die es konsumiert. Der Konsument ist ein KI-Agent. Der Produzent ist ein Mensch, der schreibt, und der dafür mehr verdient als ein Eingabefeld.
Diese Umkehrung ist die Linie von Draft_: Du nährst die KI, nicht die KI erschafft an deiner Stelle. So sehr sich OKF auch an Maschinen richtet: Alles, was es enthält, entspringt einem menschlichen Gedanken, geschrieben, strukturiert, verantwortet. Und wer die Tastatur hält, ist keine neutrale Entscheidung: Das Schreiben an einen Assistenten zu delegieren hat einen inzwischen gemessenen kognitiven Preis, von der mentalen Überlastung bis zur KI-Abhängigkeit, während die neurowissenschaftliche Hierarchie Hand > Tastatur > KI zeigt, dass es das Engagement des Schreibenden ist, das dem Erzeugten Wert verleiht. Eine Wissensbasis ist nur so viel wert wie das, was du hineinlegst. Besser, du schreibst sie selbst, in einem Werkzeug, das dafür gebaut ist.
Und tatsächlich sind die Bausteine des OKF, einer nach dem anderen, die von Draft_:
| OKF-Konvention | Draft_, im aktuellen Zustand |
|---|---|
| Verzeichnis von Markdown-Dateien | Natives Speicherformat |
| YAML-Frontmatter | Metadaten-Zone am Dokumentkopf |
| Querverweise zwischen Konzepten | Relative interne Links ([Text](../ordner/doc.md)) |
| Konzeptbaum | Spaces und Ordner |
| Versioniertes Bundle | Integrierte GitHub-Synchronisation |
| Für Menschen lesbar | Ablenkungsfreier Markdown-Editor |
Nichts zu installieren, nichts zu verkabeln. Die Übereinstimmung ist kein Zufall: OKF hat schlicht formalisiert, was gute Markdown-Editoren seit Langem tun.
Der konkrete Workflow
Du erstellst einen Space: Das ist die Wurzel deines Bundles. Darin ordnest du Ordner an (charaktere/, tabellen/, orte/…), die zu den Konzeptfamilien werden. Jedes Dokument beginnt mit einer Metadaten-Zone, in der du das Frontmatter im Klartext tippst (type: Charakter, title, tags), sogar ohne die ----Begrenzer, die Draft_ beim Export ergänzt. Der Dokumentname wird zum Dateinamen (orders → orders.md), also kontrollierst du den Pfad jedes Konzepts; deine internen Links werden zu den Kanten des Graphen, dem der Agent folgt; und die GitHub-Synchronisation verwandelt das Ganze in ein versioniertes Repository. Ein gültiges OKF-Bundle, entstanden in einem Editor, in dem du vor allem geschrieben hast.
Drei konkrete Fälle
Fall 1: die Bibel eines Fiktionsuniversums
Du schreibst einen Roman, eine Serie, ein Spiel. Du pflegst einen bibel/-Space:
charaktere/
└── elena.md (type: Charakter)
orte/
└── valdris.md (type: Ort)
fraktionen/
└── eisenpakt.md (type: Fraktion)
Elenas Blatt verweist über einfache Links auf Valdris und den Eisenpakt. Später übergibst du das Repository einem LLM: «Hier ist meine Bibel. Schreibe eine Szene, in der Elena nach Valdris zurückkehrt, treu zu ihrer Geschichte und zur Atmosphäre des Ortes.» Der Agent holt sich die relevanten Blätter, indem er den Links folgt, und schreibt innerhalb deines Universums, ohne dass du es in jeder Sitzung neu erklären musst. Deine Konsistenz wird zum Aktivposten, nicht zur mentalen Last.
Fall 2: eine lebende technische Dokumentation
Du dokumentierst eine API oder ein Produkt, nach Typ: endpoints/, konzepte/, runbooks/, jeweils mit ihrem type. Das Repository lebt neben dem Code, im selben GitHub, versioniert durch dieselben Commits. Die Doku hört auf, ein paralleles Wiki zu sein, das veraltet: Sie ist lesbar von einem CI-Agenten, vom Assistenten, der die Fragen des Teams beantwortet, oder von der Entwicklerin, die am Montag anfängt. Eine einzige Quelle, und alle, Menschen wie Maschinen, trinken daraus.
Fall 3: abfragbare Forschungsnotizen
Du sammelst Notizen zu einem Thema: Wettbewerber, Lektüren, Ideen. Jede Notiz ist ein Konzept, verbunden mit den anderen. Das synchronisierte Bundle wird zu einem externen Gedächtnis, das du abfragst: «Welche Spannungen durchziehen diese beiden Ansätze in meinen Notizen?» Das LLM durchläuft den Graphen deines Denkens, um zu antworten: nicht Wikipedia, dein eigenes Räsonnement, strukturiert und belegt.
Der Rahmen, in einer Zeile
Draft_ deckt das menschliche Glied der OKF-Kette ab: schreiben, benennen, verknüpfen, versionieren. Der Konsum geschieht danach mit jedem beliebigen LLM, und das ist der ganze Reiz eines portablen Formats. Du tippst das Frontmatter und behältst die Kontrolle über die Konsistenz, genau das Maß an Kontrolle, das man von sorgfältiger Schreibarbeit erwartet.
Kurz gesagt
- Ein OKF-Bundle ist ein Verzeichnis von Markdown + YAML-Frontmatter; Draft_ produziert es nativ.
- Space = Wurzel, Ordner = Konzepte, Metadaten-Zone = Frontmatter, Dokumentname = Dateiname, interne Links = Graph, GitHub-Sync = versioniertes Bundle.
- Du schreibst in einer echten Textverarbeitung und übergibst das Wissen dann unverändert an einen Agenten.
- Drei Spielfelder: Fiktionsbibel, lebende technische Doku, abfragbare Forschungsnotizen.
Um deine OKF-Wissensbasis aufzubauen, hast du in Draft_ bereits alles, was du brauchst: Du schreibst, du benennst, du synchronisierst. Der Rest ist Markdown, und er liegt bereits in deinen Händen.