Halten Sie Ihre Repos harness-agnostisch

Ich nutze in einer normalen Woche vier KI-Harnesses. Eine IDE mit schneller Dateinavigation, wenn ich mich orientiere, ein 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 Tool einrichte, ist für die anderen drei unsichtbar. Ein gespeicherter Session-Memory, ein Skill in einem plattformspezifischen Format, eine toolbezogene Konfigurationsdatei. All das verschwindet in dem Moment, in dem ich den selben Ordner woanders öffne.

Die Regel, nach der ich arbeite, ist daher simpel. Nur echte Dateien im Repo werden zwischen den Harnesses geteilt. Alles andere ist ein Komfort, den ich nur kurzzeitig miete.

Daraus ergeben sich drei Punkte.

1. Skills sind einfaches Markdown, kein Plattformformat

Ein Skill ist hier einfach ein Ablauf: wie man einen Bankexport importiert, wie man einen Post veröffentlicht, wie man eine Übersetzung ausführt. Jedes ernstzunehmende Tool hat mittlerweile ein eigenes Format dafür, und alle sind unterschiedlich.

Wer sie im Format eines Anbieters schreibt, erhält zwar Autocomplete, verliert aber die Portabilität. Deshalb nutze ich eine simplere Version: eine Markdown-Datei pro Ablauf in einem skills/-Ordner im Repo.

skills/
  transaction_import_skill.md
  linkedin_post_skill.md
  video_editing_skill.md

Diese liste ich dann in der Instructions-Datei mit einem Pfad und einer Zeile auf, wann sie zu verwenden sind:

Jeder Agent in jedem Tool kann diese Tabelle lesen, die benötigte Datei öffnen und den Anweisungen folgen. Es gibt keine Runtime und nichts zu registrieren. Wenn ein neues Tool dazukommt, funktioniert es ab dem ersten Tag.

2. Eine Instructions-Datei, als Symlink

AGENTS.md entwickelt sich zur Konvention, und mehrere Tools lesen diese Datei direkt. Eines der Tools, die ich nutze, sucht stattdessen nach CLAUDE.md.

Das lässt sich mit einem ln -s lösen:

ln -s AGENTS.md CLAUDE.md

Jetzt gibt es eine Datei, vier Leser und eine Regel, die ganz oben steht: Nur AGENTS.md wird bearbeitet. Der Symlink aktualisiert sich von selbst.

Was man damit vermeidet, ist nicht dramatisch, weshalb es gerade deshalb lohnenswert ist. Zwei Instructions-Dateien driften über ein paar Wochen auseinander, und am Ende folgen zwei Agenten selbstbewusst zwei verschiedenen Konventionen im selben Repo.

3. Davon ausgehen, dass kein Memory die Session überlebt

Jeder Harness verfügt über eine Form von persistentem Memory, und keiner von ihnen teilt dieses. Alles, was wichtig ist, schreibe ich daher in eine Datei: Entscheidungen in ein Log, Konventionen in die Instructions, Abläufe in einen Skill.

Das klingt nach Mehrarbeit. In der Praxis ist es die gleiche Arbeit, die man einmal statt viermal erledigt, und es hatte einen Nebeneffekt, den ich nicht erwartet hatte. Dinge, die ich für einen Agenten geschrieben habe, sind plötzlich auch für mich sechs Monate später noch lesbar. Meine eigenen Notizen wurden besser, weil ich anfing, sie für einen Leser ohne jeglichen Kontext zu schreiben.

Der Teil, den ich noch nicht gelöst habe: MCP-Server

Jeder Harness benötigt separat eingerichtete MCP-Verbindungen. Gleiche Server, gleiche Zugangsdaten, vier Setups, und sie driften auseinander.

Es ist zudem in einer Weise verschwenderisch, die sich in der Rechnung bemerkbar macht. Ein Analytics-Server, den ich nutze, stellt 275 Tools bereit. Jede dieser Definitionen mit Beschreibung und Schema belegt bei jeder Anfrage Kontext, obwohl ich vielleicht nur vier davon aufrufe.

Meine Vermutung, wohin die Reise geht: ein einziger MCP-Server, den man in jedem Harness einmal verbindet und der dann steuert, welche Sub-Server und welche Teilmenge ihrer Tools pro Projekt bereitgestellt werden. Etwas wie der Code-Modus von Cloudflare würde hier helfen, indem eine Flut von Tool-Definitionen durch eine kleine Schnittstelle ersetzt wird, die das Modell programmatisch aufruft. Es würde auch ein zweites Ärgernis beheben: dass derselbe Server je nach Projekt gegen unterschiedliche Accounts ausgeführt wird.

Falls das schon jemand gelöst hat, würde ich es gerne wissen. Es ist das letzte Stück meines Setups, das immer noch tool-basiert statt datei-basiert ist.