Jedes Projekt bekommt sein eigenes Briefing
Statt der KI jedes Mal neu zu erklären, wie ein Projekt funktioniert, hinterlege ich das einmal – in Dateien, die sie von selbst liest. Wie CLAUDE.md, Skills, MCP-Server und REST-APIs zusammenspielen, damit jedes Projekt maßgeschneidert funktioniert.
Das Problem mit dem leeren Blatt
Jede neue KI-Session könnte theoretisch bei null anfangen: Projektstruktur erklären, Regeln wiederholen, Werkzeuge aufzählen, Vorlieben nennen. Genau das habe ich am Anfang auch gemacht – bei jedem neuen Projekt wieder von vorn, in eigenen Worten, mal ausführlicher, mal knapper. Das kostete Zeit, und schlimmer: Es war inkonsistent. Was ich in einer Session erwähnt hatte, fehlte in der nächsten – und die Ergebnisse fielen entsprechend unterschiedlich aus.
Die Lösung war naheliegend, sobald ich sie mit einer vertrauten Situation verglichen habe: Wie geht man vor, wenn ein neuer Kollege oder eine neue Kollegin anfängt? Man erklärt nicht jeden Tag aufs Neue, wie die Firma tickt. Man schreibt es einmal auf – Ansprechpartner, Prozesse, Werkzeuge, No-Gos – und übergibt ein Dokument. Genau das mache ich inzwischen für jedes einzelne Projekt, nur dass der „neue Kollege" hier eine KI ist.
Für jeden Projektordner liegt ein eigenes Set an Dateien bereit, das beim Start automatisch gelesen wird: Was ist erlaubt, was nicht, welche Werkzeuge stehen bereit, wie sieht gute Arbeit in genau diesem Projekt aus. Damit steht die KI vom ersten Satz an nicht vor einem leeren Blatt, sondern vor einem fertigen Briefing.
Die vier Bausteine
Ein gutes Briefing besteht bei mir nicht aus einer einzigen Datei, sondern aus vier Bausteinen, die unterschiedliche Aufgaben übernehmen. Zusammen ergeben sie den vollständigen Kontext für ein Projekt.
Drei Beispiele aus der Praxis
Am einfachsten wird das Prinzip an konkreten Projekten sichtbar. Drei Beispiele, die ich an anderer Stelle bereits ausführlicher beschrieben habe – hier geht es nur darum, wie das jeweilige Briefing aussieht.
n8n-Workflows
Für meine n8n-Automatisierungen läuft ein eigener MCP-Server im Hintergrund. Er gibt direkten Zugriff auf Node-Suche, Validierung und Templates – die KI muss nicht raten, wie ein Node heißt oder konfiguriert wird, sondern kann live nachschauen. Mehr dazu im Artikel n8n – Automatisierung ohne Vendor-Lock-in.
Diese Homepage
Für janibu.de gibt es eine CLAUDE.md mit Farbpalette, Komponenten-Bibliothek und festen Regeln für jeden Seitentyp. Das Ergebnis: Jede neue Seite entsteht im gleichen Look, ohne dass ich Farben, Abstände oder Bausteine bei jeder Seite neu erklären muss. Wie das im Detail funktioniert, beschreibe ich in Claude Code & Codex – zwei Ansätze, ein Ziel.
Obsidian → WordPress
Ein kleines Python-Skript nutzt die WordPress-REST-API, um aus einer Markdown-Notiz in Obsidian automatisch einen fertigen Blogpost zu machen – inklusive Teaser, Kategorie und Tags. Kein MCP-Server nötig, nur eine klar definierte Schnittstelle. Ausführlich beschrieben in Vom Obsidian-Notiz zum WordPress-Blogpost.
Warum das funktioniert
Der Effekt ist in allen drei Beispielen derselbe: Die Qualität der Zusammenarbeit hängt nicht mehr davon ab, wie gut ich mich gerade an alle Details erinnere oder wie lange die letzte Session her ist. Der Kontext liegt in einer Datei, nicht in meinem Kopf.
Jedes Projekt bleibt in sich geschlossen und funktioniert unabhängig von den anderen. Neue Projekte bekommen ihr eigenes Briefing, ohne dass sich etwas gegenseitig stört. Und weil die Regeln aufgeschrieben statt gemerkt sind, bleibt die Qualität gleich – egal ob zwischen zwei Sessions ein Tag oder drei Monate liegen.
Fazit
Nicht die KI wird von Projekt zu Projekt schlauer – der Kontext, den sie bekommt, wird es. CLAUDE.md, Skills, MCP-Server und REST-APIs sind letztlich vier verschiedene Wege, derselben Idee zu folgen: Wissen einmal sauber festhalten, statt es bei jeder Gelegenheit neu zu erklären. Das Prinzip funktioniert übrigens auch ganz ohne KI – für jede Art von wiederkehrender Zusammenarbeit, bei der Übergaben sonst Reibung verursachen.