Halte deine Repos unabhängig vom Harness
In einer normalen Woche verwende ich vier KI-Harnesses. Eine IDE mit schneller Dateinavigation zum Erkunden, eine CLI für persönliche Projekte, eine Desktop-App für die Arbeit und gelegentlich ein viertes Tool, wenn ich eine zweite Meinung zum selben Repo möchte.
Das ist keine Empfehlung, sondern einfach die Situation. Und sie hat eine Konsequenz: Alles, was ich in einem davon einrichte, ist für die anderen drei unsichtbar. Ein gespeicherter Sitzungskontext, ein Skill im Format einer bestimmten Plattform, eine tool-spezifische Konfigurationsdatei. All das ist weg, sobald ich denselben Ordner woanders öffne.
Deshalb gilt für mich eine einfache Regel: Nur echte Dateien im Repo werden zwischen Harnesses geteilt. Alles andere ist eine praktische Funktion, die ich miete.
Womit ich den Ordner öffne
- Eine IDE
- Eine CLI
- Eine Desktop-App
- Was auch immer nächsten Monat erscheint
Das Repository
- skills/, eine Markdown-Datei pro Verfahren
- AGENTS.md, auf die CLAUDE.md als Symlink verweist
- Schriftlich festgehaltene Entscheidungen und Konventionen
Was jedes davon bekommt
- Dieselben Verfahren
- Dieselben Konventionen
- Vom ersten Tag an, ohne Einrichtung
Daraus folgen drei Dinge.
Eine Datei im RepoGeteilt
- Jedes Harness kann sie lesen
- Sie bleibt auch erhalten, wenn ein neues Tool dazukommt
- Sie steht im Diff und wird daher überprüft
- Du kannst sie auch in sechs Monaten noch selbst lesen
Alles innerhalb eines HarnessesGemietet
- Ein gespeicherter Sitzungskontext
- Ein Skill im Format der jeweiligen Plattform
- Eine tool-spezifische Konfigurationsdatei
- MCP-Server und ihre Zugangsdaten
Zwischen Harnesses werden nur echte Dateien geteilt, deshalb gibt es
drei Regeln
1. Skills sind einfaches Markdown, kein Plattformformat
Ein Skill ist hier einfach ein Verfahren: wie man einen Bankexport importiert, einen Beitrag veröffentlicht oder eine Übersetzung ausführt. Jedes ernstzunehmende Harness hat inzwischen ein eigenes Format dafür, und sie sind alle unterschiedlich.
Wer Skills im Format eines Anbieters schreibt, bekommt Autovervollständigung, büßt dafür aber Portabilität ein. Deshalb verwende ich eine einfachere Variante: eine Markdown-Datei pro Verfahren in einem skills/-Ordner im Repo.
skills/
transaction_import_skill.md
linkedin_post_skill.md
video_editing_skill.mdAnschließend liste ich sie in der Anweisungsdatei mit einem Pfad und einer kurzen Angabe dazu auf, wann sie verwendet werden sollen:
| Skill | Verwendung |
|---|---|
skills/transaction_import_skill.md | wenn ein Bankexport ins Hauptbuch übernommen wird |
skills/linkedin_post_skill.md | wenn aus einer Idee oder Quelle ein veröffentlichungsfertiger Beitrag werden soll |
Jeder Agent kann diese Tabelle in jedem Tool lesen, die benötigte Datei öffnen und sich daran halten. Es gibt keine Laufzeitumgebung und nichts zu registrieren. Taucht ein neues Harness auf, funktioniert es vom ersten Tag an.
2. Eine Anweisungsdatei, per Symlink eingebunden
AGENTS.md entwickelt sich zum Standard, und mehrere Tools lesen die Datei direkt. Eines der Tools, die ich verwende, sucht stattdessen nach CLAUDE.md.
Mit einem ln -s ist das kein Problem mehr:
ln -s AGENTS.md CLAUDE.mdJetzt gibt es eine Datei und vier Leser, dazu eine Regel, die ganz oben steht: Bearbeitet wird nur AGENTS.md. Der Symlink zieht automatisch nach.
Wonach Tools suchen
- Direkt nach AGENTS.md
- Nur nach CLAUDE.md
- Nach AGENTS.md, aber nur, wenn CLAUDE.md fehlt
Eine Datei auf dem Datenträger
- AGENTS.md ist die Datei
- CLAUDE.md ist ein Symlink darauf
- Bearbeitet wird immer nur AGENTS.md
Was dadurch verhindert wird
- Dass zwei Dateien auseinanderdriften
- Zwei Agenten mit zwei Konventionen
- Eine Regel, die nur in einer Datei aktualisiert wird
Was dadurch vermieden wird, ist kein großes Drama. Gerade deshalb lohnt es sich. Innerhalb weniger Wochen driften zwei Anweisungsdateien auseinander, und schon folgen zwei Agenten im selben Repository überzeugt zwei unterschiedlichen Konventionen.
3. Davon ausgehen, dass keine Erinnerung die Sitzung überdauert
Jedes Harness hat eine eigene Form von dauerhaftem Speicher, und diese Speicher lassen sich nicht gemeinsam nutzen. Deshalb halte ich alles Wichtige in Dateien fest: Entscheidungen in einem Protokoll, Konventionen in den Anweisungen, Abläufe in einem Skill.
Das klingt nach zusätzlicher Arbeit. In der Praxis ist es dieselbe Arbeit, nur einmal statt viermal. Außerdem hatte es einen unerwarteten Nebeneffekt: Was ich für einen Agenten aufschreibe, kann ich sechs Monate später selbst noch lesen. Meine Notizen wurden besser, weil ich angefangen habe, für Leser ohne jeden Kontext zu schreiben.
Was ich noch nicht gelöst habe: MCP-Server
Jedes Harness muss separat für die MCP-Verbindungen eingerichtet werden. Dieselben Server, dieselben Zugangsdaten, vier Konfigurationen, die auseinanderdriften.
Außerdem ist das auf eine Weise ineffizient, die sich auf der Rechnung bemerkbar macht. Ein Analytics-Server, den ich nutze, stellt 275 Tools bereit. Jede dieser Definitionen samt Beschreibung und Schema belegt bei jeder Anfrage Kontext, obwohl ich vielleicht vier davon aufrufe.
Ein MCP-Server bei jeder Anfragebevor ich überhaupt etwas gefragt habe
- 275 Tool-DefinitionenJede mit Beschreibung und Payload-Schema
- Die vier, die ich tatsächlich aufrufeOben bereits mitgezählt. Maßstabsgetreu dargestellt.
- Left for your actual work
Ich vermute, dass es auf einen einzigen MCP-Server hinausläuft, den man in jedem Harness einmal verbindet. Dieser verwaltet dann, welche Unterserver und welche ihrer Tools pro Projekt verfügbar sind. Cloudflares Code-Modus wäre hier hilfreich: Statt einer Flut von Tool-Definitionen gäbe es eine kleine Schnittstelle, die das Modell programmatisch aufruft. Damit ließe sich auch ein weiteres Ärgernis beheben: denselben Server je nach Projekt mit unterschiedlichen Konten zu betreiben.
Falls das schon jemand gelöst hat, würde ich gern davon erfahren. Es ist der letzte Teil meiner Einrichtung, der noch an ein Tool statt an eine Datei gebunden ist.