Agent Plugin in der Praxis: Eine LaTeX-Schreibstube für Claude Code

In den ersten beiden Teilen dieser Serie ging es um den neuen Plugin-Standard und die Begriffe dahinter. Theorie ist geduldig – deshalb haben wir die Probe aufs Exempel gemacht und unser erstes eigenes Agent Plugin gebaut: die Schreibstube. Sie erstellt Geschäftsbriefe der Lauth IT GmbH nach DIN 5008, mit LaTeX gesetzt, im Corporate Design, und prüft das Ergebnis selbstständig visuell. Hier ist, was wir dabei gelernt haben.

Das Problem: Dokumente, die niemand gern von Hand setzt

Geschäftsbriefe sind ein klassischer Kleinkram-Fall: Sie fallen unregelmäßig an, müssen formal korrekt sein (DIN 5008, Falzmarken, Anschriftfeld) und im Corporate Design erscheinen. Markdown-Export sieht dafür nicht gut genug aus – echter Satz mit KOMA-Script und LuaLaTeX schon. Wer an dieser Stelle „aber wir machen das in Word“ denkt: Das Konzept funktioniert dort genauso – dazu kommen wir am Ende. Aber die Hürde war bisher: Vorlage suchen, Konventionen erinnern, kompilieren, PDF kontrollieren. Genau diese Schleife wollten wir einem Agenten übergeben.

Die Bausteine des Plugins

Ein Agent Plugin bündelt Skills, Agenten, Hooks und Skripte in einem installierbaren Paket. Bei der Schreibstube sieht das so aus:

Der wichtigste Architektur-Entscheid steckt im Briefbogen: Absenderdaten, Logo, Ränder und Schriften stehen ausschließlich in einer zentralen .lco-Datei (KOMA-Scripts Format für Briefvorlagen). Einzelne Briefe laden sie nur. Ohne diese Regel „repariert" ein Agent bei einem Layoutwunsch gern mal den einzelnen Brief statt der Vorlage – und nach zehn Briefen driftet das Erscheinungsbild auseinander.

Corporate Design bis in die Schrift: warum LuaLaTeX

Ein Detail mit Wirkung: Wir kompilieren mit LuaLaTeX statt klassischem pdfLaTeX, weil es TrueType-Schriften direkt einbindet. Die Hausschrift liegt damit als Font-Dateien im Plugin selbst, das Logo als Vektor-PDF daneben — wer das Plugin installiert, bekommt das komplette Corporate Design mitgeliefert, ohne Schriften zu installieren oder Farbwerte nachzuschlagen. Genau das meint „Toolchain als Paket": Auch die Gestaltung reist mit.

Der Prüf-Subagent: teure Arbeit auslagern

Das eigentliche Aha-Erlebnis war der Prüf-Subagent. Visuelle Kontrolle ist für ein Sprachmodell teuer: kompilieren, jede Seite als Bild rendern, Bilder betrachten. All das würde den Hauptkontext fluten. Stattdessen delegiert der schreibende Agent an einen Prüfer, der in seinem eigenen Kontext arbeitet:

flowchart LR
  A["Autor<br/><i>Agent, Mitarbeiter<br/>oder beide</i>"] -->|delegiert| P["Prüf-Subagent"]
  P --> K["latexmk<br/><i>kompilieren</i>"]
  K --> R["pdftoppm<br/><i>Seiten als PNG, 100 dpi</i>"]
  R --> C["visuelle Kontrolle<br/><i>Layout, Falzmarken, Überläufe</i>"]
  C -->|"nur Problemliste<br/>oder OK"| A
  style P stroke:#cc171a,stroke-width:2.5px

Drei Details machen den Unterschied: Die Auflösung ist bewusst niedrig (100 dpi reichen, um Layoutfehler zu sehen, und sparen massiv Tokens). Der Prüfer gibt nur eine kompakte Problemliste zurück – Logs und Bilder bleiben in seinem Kontext, sonst wäre nichts gewonnen. Und der Skill verpflichtet den Hauptagenten, erst zu antworten, wenn der Prüfer „OK" meldet. Die Schleife schreiben → prüfen → korrigieren läuft damit autonom. Bemerkenswert dabei: Der Autor ist austauschbar. Ob der Agent den Brief schreibt, eine Mitarbeiterin selbst formuliert oder beide gemeinsam am Text arbeiten — die Prüf-Schleife bleibt dieselbe, denn der Prüfer lässt sich genauso auf von Hand geschriebene Dokumente ansetzen. Das Plugin ersetzt also niemanden, es nimmt jedem Autor die lästigste Etappe ab.

Der Hook: deterministisch, wo der Skill nur probabilistisch ist

Dateinamen sind eine Kleinigkeit mit großer Wirkung: final_v2.tex und neu.tex sind genau das, was Agenten ohne Regel produzieren. Unsere Konvention (JJJJ-MM-TT_typ_empfaenger_betreff.tex) steht zwar im Skill – aber Anweisungen können bei langen Sitzungen aus dem Blick geraten. Hier zeigt sich ein Grundprinzip beim Bauen mit Sprachmodellen: Eine Skill-Anweisung wirkt probabilistisch — sie wird sehr wahrscheinlich befolgt, garantiert ist es nicht. Ein Hook dagegen ist deterministisch — Code, der immer läuft, egal wie lang die Sitzung ist. Für Stilfragen genügt das Wahrscheinliche; Regeln, die nie brechen dürfen, brauchen die deterministische Schicht darunter. Deshalb sichert ein PreToolUse-Hook die Konvention technisch ab: Er prüft vor jedem Schreiben einer Briefdatei den Namen und blockt den Vorgang mit einer erklärenden Meldung, wenn er nicht passt. Der Agent liest die Meldung und korrigiert sich selbst. Wichtig dabei: Der Hook greift nur bei echten Lauth-Briefen (erkennbar an der Dokumentklasse), fremde Dateien bleiben unbehelligt.

Nicht nur Briefe: Reports aus derselben Werkstatt

Was für Briefe funktioniert, skaliert auf andere Dokumenttypen: Die Schreibstube enthält inzwischen einen zweiten Dokumenttyp Report — mit eigener Stildatei, eigener Vorlage und einem eigenen Agenten, aber denselben Konventionen und demselben Prüfer. Der Grenznutzen ist enorm: Der erste Dokumenttyp kostet die Denkarbeit (Konventionen, Prüf-Schleife, Abhängigkeiten), jeder weitere ist im Wesentlichen eine Vorlage plus ein kurzer Agent. Berichte, Protokolle, Angebote — die Werkstatt wächst mit.

Vom Dokument zur Ablage: MCP als nächster Baustein

Ein Baustein aus dem Plugin-Standard fehlt in der Schreibstube bislang bewusst: ein MCP-Server. Dabei liegt der Anwendungsfall auf der Hand — das fertige PDF gehört nicht in ein lokales Verzeichnis, sondern ins Dokumentenmanagement. Ein Ablage-MCP würde die Schleife vervollständigen: schreiben, prüfen, ablegen, inklusive Metadaten wie Datum, Dokumenttyp und Empfänger, die dank der Dateinamen-Konvention ohnehin strukturiert vorliegen. Bei uns wäre das Ziel unser DMS Paperless; für SharePoint oder Teams gilt exakt dasselbe Muster — wie man solche MCP-Server baut, haben wir bereits beschrieben. Und da Plugins MCP-Server mitliefern können, bliebe auch das ein Teil desselben Pakets: einmal installieren, und die komplette Strecke vom Diktat bis zur archivierten Akte steht.

Die ehrliche Lektion: Abhängigkeiten reisen nicht mit

Ein Plugin kann LaTeX nicht mitinstallieren – latexmk, poppler-utils und die richtigen TeX-Pakete sind Systemsache. Wer je gesucht hat, welches Paket ngerman für die deutsche Silbentrennung enthält, weiß: Das ist die eigentliche Arbeit. Unsere Lösung ist ein check-deps.sh, das nicht nur Programme prüft, sondern per kpsewhich die konkreten Stildateien, die unsere Vorlage lädt – und bei Fehlern gleich die passenden Paketnamen nennt. Die mühsam ermittelte Zuordnung steht damit im Skript statt im Kopf, und der Agent kann die Installation nach Rückfrage selbst ausführen.

Entwickeln, testen, konservieren

Während der Entwicklung braucht es keinen Marketplace: claude --plugin-dir /pfad/zur/schreibstube lädt das Plugin direkt aus dem Arbeitsverzeichnis — ändern, neu starten, testen. Erst der „released" Stand wandert ins Repository. Und noch ein Betriebs-Tipp aus der Praxis: Läuft die Umgebung in einer VM oder einem Container, lohnt nach dem fertigen Setup ein Snapshot. Die einmal mühsam zusammengestellte TeX-Umgebung ist damit konserviert, und das Abhängigkeits-Skript degradiert vom Installationshelfer zum Sicherheitsnetz für neue Maschinen — so herum ist es gedacht.

Verteilung: ein Repository für alles

Die Schreibstube lebt in einem Repository agent-extensions zusammen mit einer marketplace.json – Claude Codes Marketplace-Format ist im einfachsten Fall genau das: ein Git-Repo mit Katalogdatei. Neues Plugin, neuer Ordner, ein Eintrag, fertig. Da wir neben Claude Code auch GitHub Copilot einsetzen, ist das Repo bewusst werkzeugneutral aufgebaut; Skills im offenen SKILL.md-Format versteht ohnehin beides. Die Verteilung über unseren eigenen Git-Server hatte allerdings eine Tücke, die einen eigenen Beitrag wert ist – dazu in Kürze mehr.

Geht das auch mit Word?

Ja - das Muster ist nicht an LaTeX gebunden. An die Stelle der .lco tritt dann eine Word-Vorlage (.dotx), der Agent befüllt sie über Open-XML-Werkzeuge oder eine Markdown-Konvertierung, und Prüf-Subagent wie Namenskonvention funktionieren identisch. Wir haben uns bewusst für LaTeX entschieden: zugegeben etwas nerdig, dafür absolut layoutstabil - ein Dokument sieht bei jeder Kompilierung auf jedem Rechner exakt gleich aus, während Word-Layouts je nach Version, Druckertreiber und verfügbaren Schriften gern einmal umbrechen. Wo Dokumente ohnehin von Kolleginnen und Kollegen in Word weiterbearbeitet werden sollen, ist die .dotx-Variante dagegen der pragmatische Weg. Der Punkt ist: Das Plugin-Konzept bleibt dasselbe - zentrale Vorlage, feste Regeln, automatische Prüfung. Die Wahl des Satzsystems ist ein Detail dahinter.

Fazit

Der Standard hält, was er verspricht: Aus verstreuten Konventionen, Vorlagen und Prüfroutinen ist ein installierbares Paket geworden, das die komplette Schreibschleife kapselt. Der Aufwand lag nicht im Plugin-Format – Manifest und Struktur sind an einem Nachmittag erledigt –, sondern dort, wo er hingehört: in den fachlichen Regeln, die vorher nur in Köpfen existierten.

Nebenbei spannt dieser Stack fast fünfzig Jahre Technikgeschichte auf: Das Satzsystem geht im Kern auf TeX von 1978 zurück, kompiliert wird mit dem deutlich jüngeren LuaLaTeX, dazwischen liegen KOMA-Script aus den Neunzigern sowie SSH und Git aus den Nullerjahren — und obenauf arbeiten Agenten von 2026. Dass das reibungslos zusammenspielt, ist kein Zufall: Jede Schicht ist stabil genug geworden, dass die nächste darauf bauen konnte.

Sie überlegen, welche wiederkehrenden Abläufe sich in Ihrem Unternehmen so kapseln ließen? Auf unserer Seite KI-Agenten für Unternehmen zeigen wir, wie wir bei Konzeption und Umsetzung unterstützen.