Die Content-Maschine: Wenn dein Vault weiß was du erzählen solltest
Es gibt ein Problem das jeder kennt, der Content erstellt: Die besten Ideen kommen genau dann, wenn man nicht ans Content-Erstellen denkt — beim Debuggen, beim Einrichten eines Servers, mitten in einer technischen Diskussion mit einer KI.
Und dann passiert eine von drei Sachen: Man vergisst es sofort. Oder man denkt „das wäre ein guter Post“, notiert es irgendwo hin, und drei Wochen später findet man den Zettel nicht mehr. Oder — am frustrierendsten — man findet den Zettel, aber der Kontext ist weg und man weiß nicht mehr, warum es ein guter Post gewesen wäre.
Ich habe dieses Problem gelöst, und zwar nicht mit Disziplin (die habe ich nicht in diesem Bereich) oder einer Content-Routine (die halte ich nicht durch), sondern mit einer Erweiterung des Systems aus Teil 2, die automatisch erkennt wann eine Session Content-Potenzial hat.
Das Prinzip: Der Content-Scout
In Teil 2 habe ich flush.py beschrieben — den Prozess, der nach jeder Session die wichtigen Erkenntnisse extrahiert und in die Daily Note schreibt. Der Content-Scout ist eine Erweiterung genau dieses Prozesses: kein separates Tool, kein extra Hook, sondern ein zusätzlicher LLM-Call im gleichen Hintergrundprozess, der ohnehin schon läuft.
Der Ablauf sieht so aus:
Session endet
→ flush.py extrahiert Session-Wissen (wie in Teil 2)
→ flush.py bewertet Content-Potenzial (NEU)
→ Prüft alle Kanäle: Blog, LinkedIn, YouTube, Podcast, Newsletter, Twitter, Shorts
→ Filter: "Hätte mir das geholfen, als ich davor saß?"
→ Bei Treffer: automatisch in Ideen-Backlog eingetragen
→ In Daily Note dokumentiert
Der zusätzliche Aufwand ist minimal, weil der LLM den gleichen Kontext liest, den er für die Wissensextraktion ohnehin schon analysiert hat — er gibt nur ein kurzes Urteil ab.
Der Prompt: Woran erkennt man guten Content?
Die Qualität des Scouts steht und fällt mit dem Prompt — also der Anweisung, nach der die KI bewertet ob eine Session content-tauglich ist. Hier ist die Logik die ich verwende:
Fünf Content-Muster: 1. Problem → Lösung — Ein konkretes Problem wurde gelöst (How-To, Tutorial) 2. Entscheidung — Zwischen Optionen abgewogen (Vergleich, Erfahrungsbericht) 3. Erkenntnis — Etwas Unerwartetes gelernt (Gotcha, Lesson Learned) 4. System gebaut — Ein Workflow, eine Architektur, ein Tool aufgesetzt 5. Fehler gemacht — Etwas ging schief und wurde gefixt (ehrlicher Bericht)
Acht Kanäle: – Blog (mehrzweckroboter.de) — tiefere technische Artikel – LinkedIn Post — kurz, pointiert, eine Erkenntnis – LinkedIn Artikel — längerer Fachbeitrag – YouTube Video — Screencast, Tutorial, Walkthrough – YouTube Short / Reel — 60 Sekunden, ein Punkt – Podcast / Audio — Diskussionsthema, Erfahrungsbericht – Twitter/X Thread — kompakte technische Erklärung – Newsletter — wöchentliche Einordnung
Der Filter: Die zentrale Frage ist simpel: „Hätte mir das geholfen, als ich davor saß?“ Das ist der gleiche Qualitätsfilter den ich auch manuell verwende, wenn ich überlege ob etwas ein Post wird. Wenn die Antwort nein ist — reine Verwaltung, triviale Änderungen, Routine — kommt NO_CONTENT zurück.
Was passiert bei einem Treffer
Wenn der Scout Content-Potenzial erkennt, passieren zwei Dinge gleichzeitig:
1. Automatischer Eintrag im Ideen-Backlog:
Das ist der wichtigere Teil: Der Scout schreibt eine Zeile in eine Markdown-Tabelle — und zwar im gleichen Ideen-Backlog, den ich auch manuell für meine Content-Planung nutze. Die automatisch erkannten Ideen landen in einer eigenen Sektion „Auto-Capture (Session-Scout)“, sodass ich auf einen Blick sehe, was das System gefunden hat und was ich selbst eingetragen habe.
### Auto-Capture (Session-Scout)
| Idee | Story-Kern | Asset/Kanal | Status |
|------|-----------|-------------|--------|
| Obsidian Knowledge Base System | Wie ich Karpathys Wiki-Konzept in meinen Vault integriert habe — Hooks, Compiler, automatische Artikel | Blog: Serie + LinkedIn: Post + YouTube: Walkthrough | Idee |
2. Dokumentation in der Daily Note:
### Content-Scout (14:45)
Content-Scout: Idee erkannt und in Ideen-Backlog eingetragen.
> Obsidian Knowledge Base System | Wie ich Karpathys Wiki-Konzept in meinen Vault integriert habe | Blog: Serie + LinkedIn: Post + YouTube: Walkthrough | Idee
So kann ich in der Daily Note nachvollziehen wann welche Idee erkannt wurde — und im Ideen-Backlog alle Ideen an einem Ort sehen.
Warum mehrere Kanäle gleichzeitig
Die meisten Content-Systeme denken in einem einzigen Kanal: „Schreib einen Blogpost.“ Aber in der Realität ist ein gutes Thema selten nur für einen Kanal gut. Nehmen wir ein SSH-Tunnel-Tutorial als Beispiel — das ist gleichzeitig:
- Ein Blogpost (ausführlich, mit Code-Beispielen)
- Ein LinkedIn-Post (die Erkenntnis in 5 Sätzen)
- Ein YouTube-Video (Screencast: live einrichten)
- Ein YouTube-Short (60 Sek: „Dieser eine SSH-Config-Trick“)
- Ein Twitter-Thread (Schritt für Schritt, 5 Tweets)
Der Scout schlägt deshalb nicht „einen“ Kanal vor, sondern alle die passen. Die Entscheidung, welche davon ich tatsächlich bespiele, liegt nach wie vor bei mir — aber ich muss nicht mehr bei jeder Idee überlegen „wäre das auch ein Video?“. Das System gibt mir die Optionen, ich treffe die Auswahl.
Der Ideen-Backlog: Manuell + Automatisch
Ein wichtiges Detail: Mein Ideen-Backlog existierte schon bevor der Content-Scout existierte. Er hat Kategorien (Infrastruktur, KI, Robotik), Status-Werte (Idee, Bereit, In Arbeit, Veröffentlicht) und eine Spalte für den Story-Kern — also die zentrale Aussage, um die sich ein Beitrag drehen würde.
Der Scout füttert genau diesen bestehenden Backlog, nicht einen separaten. Die einzige Trennung ist die Sektion innerhalb der Datei — „Auto-Capture“ vs. die manuellen Kategorien. So entsteht kein Paralleluniversum, sondern alles landet an einem Ort und im gleichen Format.
Was ich in der Praxis erwarte: Die meisten Auto-Captures werden in der Kategorie „Idee“ bleiben und dort auf mein Urteil warten. Manche werden zu „Bereit“ hochgestuft, wenn ich sie sehe und denke „ja, das ist gut“. Manche werden verworfen. Und manche — das ist die eigentliche Hoffnung — werden mich überraschen: Ideen die ich selbst nicht als content-tauglich erkannt hätte, weil ich beim Arbeiten zu sehr im Tunnelblick war.
Das ist der eigentliche Wert des Systems: nicht die Ideen die ich sowieso gehabt hätte, sondern die, die mir sonst entgangen wären.
Ein konkretes Beispiel
Diese Session — in der ich das Knowledge-Base-System gebaut habe — hat folgenden Content produziert:
| Was passiert ist | Content-Potenzial |
|---|---|
| Karpathys Gist analysiert | Blog: Erklärung des Konzepts |
| Cole’s Repo komplett gelesen | Blog: Technischer Deep-Dive |
| SessionStart-Hook statt Uhrzeit-Trigger | LinkedIn: Kurzer Post über Design-Entscheidung |
| 27 Daily Notes automatisch kompiliert | YouTube: Screencast, Live-Demo |
| Content-Scout implementiert | Blog: Meta-Artikel über das System selbst |
| Python 3.9 zu alt, uv managed 3.12 | Twitter: Quick Tip zu uv |
Aus einer einzelnen Session: potentiell 6 Content-Pieces über 4 Kanäle. Davon wird nicht alles umgesetzt. Aber die Ideen sind da, dokumentiert, mit Kontext.
Und genau diese Session hat zu dieser Blogserie geführt.
Die Meta-Ebene: Content über Content
Es gibt etwas angenehm Ironisches daran, einen Blogpost über ein System zu schreiben, das Blogpost-Ideen generiert.
Aber genau das zeigt, warum das System funktioniert: Diese dreiteilige Serie war keine geplante Content-Strategie. Sie ist organisch entstanden — ich habe ein System gebaut, das System hat erkannt dass der Bauprozess selbst content-tauglich ist, und jetzt liest du das Ergebnis davon.
Das ist der fundamentale Unterschied zu „ich brauche eine Content-Routine“. Es gibt keine Routine. Es gibt ein System, das aufpasst während ich arbeite — und mir hinterher sagt, was davon andere interessieren könnte.
Was das System NICHT kann
Ehrlichkeit ist mir wichtig, besonders bei einem Meta-System das sich leicht überhypen lässt:
1. Es schreibt keinen Content. Der Scout erkennt Potenzial und schlägt Kanäle vor, aber schreiben muss ich immer noch selbst (oder Claude bitten, einen ersten Entwurf zu machen). Das System ist ein Scout, kein Ghostwriter — und das ist auch gut so, weil guter Content meine Perspektive braucht, nicht nur Fakten.
2. Es hat keinen Geschmack. Der Filter „Hätte mir das geholfen?“ ist ein guter Proxy, aber er wird manchmal daneben liegen. Zu viele Ideen sind besser als zu wenige — aber es wird auch Rauschen geben, und die manuelle Kuration bleibt ein fester Bestandteil des Workflows.
3. Es kennt meine Audience nicht wirklich. Der Scout weiß was technisch passiert ist, aber nicht ob meine LinkedIn-Follower sich für SSH-Tunnel interessieren oder ob das eher ein Blog-Thema ist. Audience-Fit bleibt mein Job.
4. Es braucht reichhaltige Sessions. Wenn ich eine Session lang nur Dateien verschiebe und Ordner aufräume, kommt NO_CONTENT zurück — und das ist korrekt so. Der Scout ist genau so gut wie die Sessions die ich führe. Sessions in denen ich Probleme löse, Entscheidungen treffe oder Erkenntnisse habe, sind ergiebig. Verwaltungs-Sessions nicht.
Der Gesamtablauf: Alles zusammen
Um das Gesamtbild zu sehen, hier der komplette Zyklus von einer Arbeitssession bis zum fertigen Content-Piece:
1. Ich arbeite in Obsidian mit Claude
↓
2. SessionEnd-Hook extrahiert Konversation
↓
3. flush.py im Hintergrund:
a) Extrahiert Session-Wissen → Daily Note
b) Bewertet Content-Potenzial → Ideen-Backlog
↓
4. Nächster Session-Start:
a) KB-Index wird injiziert (Claude "erinnert sich")
b) Unkompilierte Daily Notes werden kompiliert
↓
5. compile.py im Hintergrund:
→ Daily Notes werden zu Konzept-Artikeln
→ Knowledge Base wächst
↓
6. Ich öffne den Ideen-Backlog
→ Auto-Capture zeigt neue Ideen mit Kanal-Vorschlägen
→ Ich entscheide was ich umsetze
↓
7. Content entsteht — unterstützt durch den vollen Vault-Kontext
Das ist ein sich selbst verstärkender Kreislauf: Arbeit generiert Wissen, Wissen generiert Content-Ideen, und die Content-Erstellung ist selbst wieder Arbeit die neues Wissen generiert. Kein definierter Anfang, kein Ende.
Was ich aus dem Aufbau gelernt habe
Drei Erkenntnisse, die über das rein technische Setup hinausgehen und die ich so nicht erwartet hatte:
1. Automatisierung ist kein Ersatz für gute Arbeit. Das System funktioniert nur dann gut, wenn die Sessions selbst substanziell sind. Wenn ich den ganzen Tag nur Dateien hin- und herschiebe, gibt es nichts zu erinnern und nichts zu posten. Das System verstärkt die Qualität meiner Arbeit — aber es erzeugt sie nicht. Es ist ein Multiplikator, kein Generator.
2. Die drei Vorbilder hatten jeweils einen blinden Fleck. Karpathy hatte das Konzept, aber keinen Code. Cole hatte den Code, aber keinen Vault. Julian hatte den Vault, aber kein Gedächtnis. Und keiner der drei hatte automatische Content-Erkennung. Erst die Kombination ergibt ein System, das mehr ist als die Summe seiner Teile.
3. Das beste Feature ist das unsichtbare. Ich merke nicht, dass Hooks laufen. Ich merke nicht, dass Daily Notes kompiliert werden. Ich merke nicht, dass der Scout jede Session bewertet. Ich arbeite einfach — und das System arbeitet im Hintergrund mit. Genau so soll es sein.
Ausblick: Was als nächstes kommt
Das System ist seit heute live, und es wird sich zeigen wie gut es in der Praxis funktioniert. Ein paar offene Fragen, die mich interessieren:
- Wie oft wird der Content-Scout richtig liegen — und wie oft wird er Rauschen produzieren?
- Wie skaliert die Knowledge Base über Monate hinweg, wenn jeden Tag neue Artikel dazukommen?
- Ab wann brauche ich tatsächlich eine Suchschicht statt des einfachen Index?
Aber die spannendste Frage ist eine andere: Wie verändert sich die Art wie ich arbeite, wenn ich weiß dass alles erinnert und bewertet wird? Arbeite ich bewusster? Erkläre ich Entscheidungen besser, weil ich weiß dass sie extrahiert werden? Experimentiere ich mehr, weil der Fehler nicht verloren geht sondern zum Lernmaterial wird?
Mal sehen. Ich berichte.





