code2prompt: Ein Rust-CLI, das ein Repository in einen einzigen Prompt verwandelt

Welches Problem code2prompt löst und für wen es gedacht ist

Wer einem Sprachmodell eine Frage zu einem Repository stellt, kopiert Dateien von Hand, vergisst die Hälfte und formatiert den Rest unterschiedlich. code2prompt nimmt einen Verzeichnispfad entgegen und erzeugt daraus einen einzigen, formatierten Text: einen Quellbaum plus den Inhalt der ausgewählten Dateien. Die README beschreibt das als Kontextaufbereitung für ChatGPT, für Agenten und für MCP-Server. Die Zielgruppe ist damit enger, als der Name vermuten lässt. Angesprochen sind Entwickler, die denselben Ausschnitt wiederholt an ein Modell geben, und Integratoren, die den Vorgang in Skripte oder Agenten einbetten. Für eine einmalige Frage zu einer einzelnen Datei ist der Aufwand größer als der Nutzen. Interessant wird das Werkzeug dort, wo Auswahlregeln, Template und Tokenbudget über mehrere Läufe hinweg gleich bleiben sollen.

Der Ablauf: Dateien traversieren, filtern, in ein Template rendern

Die README nennt eine Kernbibliothek, die für das sichere Durchlaufen von Verzeichnissen, die Beachtung der .gitignore-Regeln und den Aufbau der Git-Metadaten zuständig ist. Auf dieser Bibliothek sitzen CLI, Python-Bindings und ein MCP-Server. Der Datenfluss ist damit linear: Ein Verzeichnis wird eingelesen, Auswahl und Ausschluss per Glob-Muster und .gitignore greifen, die verbleibenden Dateien werden je nach Format aufbereitet, und ein Handlebars-Template setzt daraus den Prompt zusammen. Die README erwähnt ausdrücklich vereinfachtes Lesen verschiedener Formate wie CSV, Notebooks und JSONL. Das ist der Punkt, an dem sich code2prompt von einem einfachen cat über alle Dateien unterscheidet: Die Struktur des Quellbaums bleibt im Ergebnis erhalten, und der Inhalt wird pro Datei so aufbereitet, dass ein Modell Dateigrenzen erkennen kann. Wer schon einmal versucht hat, einem Modell aus einem unstrukturierten Textblock zu erklären, welche Funktion in welcher Datei liegt, kennt den Unterschied.

Installation und erste Befehle

Die README nennt drei Wege. Über Cargo: cargo install code2prompt. Wer Clipboard-Integration unter Wayland braucht, installiert mit dem Feature-Flag, also cargo install --features wayland code2prompt. Über Homebrew: brew install code2prompt. Für die Python-Bindings: pip install code2prompt-rs. Der einfachste Aufruf erzeugt einen Prompt aus dem aktuellen Verzeichnis und schreibt nach stdout: code2prompt . Mit -c landet das Ergebnis in der Zwischenablage. In eine Datei geht es mit code2prompt path/to/project --output-file prompt.txt. Diese Befehle stammen unverändert aus der README. Wer den interaktiven Weg bevorzugt, findet laut Feature-Liste eine TUI. Für Agenten nennt die README einen separaten Installer über npx skills add mufeedvh/code2prompt, der eine Skill-Datei und ein Template hinzufügt; das CLI selbst wird dabei nicht mitinstalliert.

Token-Schätzung: was gezählt wird und was nicht

Die README ist bei diesem Punkt ungewöhnlich präzise, und das ist der wichtigste Absatz für jeden, der das Werkzeug produktiv einsetzt. Die Schätzung erfolgt parallel pro Datei, plus ein geschätzter Aufschlag für das Template und optional für Zeilennummern. Der fertig gerenderte Prompt wird nicht erneut tokenisiert. Die Schätzung enthält außerdem nicht die JSON-Hülle der Ausgabe. Wer also --output-format json verwendet, bekommt eine Zahl, die systematisch unter dem liegt, was tatsächlich an das Modell geht. Dasselbe gilt, wenn das Template viel statischen Text enthält: Der Aufschlag ist eine Schätzung, keine Messung. Für die Praxis heißt das, die Zahl als Budgetindikator zu behandeln und nicht als Freigabe. Wer knapp an einem Kontextlimit arbeitet, sollte den gerenderten Prompt mit dem Tokenizer des Zielmodells nachzählen. Die README sagt selbst, dass die vollständige Neu-Tokenisierung nicht stattfindet; das ist eine bewusste Entscheidung zugunsten der Geschwindigkeit, und der Preis dafür ist Genauigkeit.

Git-Metadaten, Auswahlregeln und die Frage der Weitergabe

Die README nennt Git-Integration als Feature: Diffs, Logs und Branch-Vergleiche lassen sich in den Prompt aufnehmen. Zusammen mit der Quellbaum-Ausgabe entsteht damit ein Dokument, das nicht nur Code, sondern auch Pfadstruktur und Versionsgeschichte enthält. Das ist für Reviews und für Fragen der Art was hat sich seit diesem Branch geändert nützlich. Es ist gleichzeitig ein Punkt, den man vor dem Teilen bedenken sollte: Ein Prompt, der Dateipfade und Commit-Historie enthält, transportiert Informationen über die Projektstruktur, die in einem geteilten Chatverlauf oder in einem externen Dienst landen. Die README behandelt diesen Aspekt nicht. Wer code2prompt in einer Umgebung einsetzt, in der Prompts protokolliert oder an Dritte gesendet werden, sollte die Auswahlregeln und die Git-Optionen bewusst setzen, statt die Standardausgabe ungeprüft weiterzugeben. Das ist keine Schwäche des Werkzeugs, sondern eine Eigenschaft jedes Verfahrens, das ein Repository in einen Text verwandelt.

Grenzen: große Repositories, Monorepos, Nicht-Text-Dateien

Der Ansatz hat eine harte Grenze: Er kopiert Inhalt. Ein Repository, das größer ist als das Kontextfenster des Zielmodells, lässt sich damit nicht vollständig übergeben, und die Filterung per Glob-Muster wird dann zur manuellen Partitionierung. Genau hier liegt der Unterschied zu Werkzeugen, die ein Repository nicht als Text, sondern als Karte erschließen. Die README von code2prompt beschreibt diesen Gegensatz selbst, wenn sie in der Skill-Beschreibung empfiehlt, zuerst eine kompakte Karte von Funktionen und Klassen zu inspizieren und erst danach relevante Quelldateien und Tests zu lesen. Das ist ein Eingeständnis, dass die vollständige Kopie nicht immer der richtige erste Schritt ist. Ein zweiter Punkt: Binärdateien, Bilder und große generierte Artefakte gehören nicht in einen Prompt. Die .gitignore-Regeln fangen einen Teil davon ab, aber nur, wenn das Repository sie korrekt pflegt. Und drittens: Die Token-Schätzung ist, wie oben beschrieben, eine Schätzung. Wer sie als harte Obergrenze behandelt, wird gelegentlich ein Modell mit einem zu langen Prompt konfrontieren.

Wann ein anderes Werkzeug die bessere Wahl ist

Der naheliegende Vergleich ist ein Repository-Mapping-Werkzeug, das nicht den Dateiinhalt, sondern eine komprimierte Struktur ausgibt: Signaturen, Klassenhierarchien, Aufrufbeziehungen. Die README verweist für diesen Zweck auf sem-core und eine entity-map-Funktion, die als optionales Feature installiert wird, mit einem Verzeichnisbaum als Rückfalllösung für Standard-Builds. Der Unterschied im Ansatz ist grundlegend. code2prompt liefert den vollständigen Text und überlässt die Auswahl dem Modell. Ein Mapper liefert eine Abstraktion und zwingt das Modell, gezielt nachzulesen. Für die Frage, wo im Repository eine bestimmte Funktion definiert ist, ist der Mapper effizienter. Für die Frage, ob diese Funktion einen Fehler enthält, braucht das Modell den Code, und dann ist code2prompt mit einem eng gefassten Pfad das passendere Werkzeug. Beide Ansätze schließen sich nicht aus; die README behandelt die Karte ausdrücklich als ersten Schritt vor dem Lesen der Quelldateien.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Das Projekt steht unter MIT-Lizenz. Das ist eine permissive Lizenz: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Lizenztext und der Urheberrechtshinweis beibehalten werden. Für die meisten kommerziellen Einsätze ist das unproblematisch. Wer den Code jedoch in ein eigenes Produkt einbettet, sollte die Bedingungen selbst prüfen und nicht auf eine Zusammenfassung vertrauen. Zur Wartung: Die letzten hier bekannten Releases sind v4.2.0 vom 11. Dezember 2025 und v4.0.2 vom 18. September 2025, der letzte Push auf den Hauptzweig datiert vom 7. September 2026. Das Projekt ist nicht archiviert. Zwischen v3.0.2 und v4.0.2 liegt ein Versionssprung, der auf Änderungen an der Schnittstelle hindeuten kann; wer das CLI in Skripten aufruft, sollte die Release Notes vor einem Upgrade lesen. Die Python-Bindings werden separat über PyPI verteilt, sodass CLI und SDK unterschiedliche Versionsstände haben können. Wer beide einsetzt, muss die Versionen getrennt verfolgen. Ein konkreter erster Prüfschritt vor dem produktiven Einsatz: einen Lauf mit --output-format json gegen das eigene Repository ausführen, den gerenderten Prompt mit dem Tokenizer des Zielmodells nachzählen und die Differenz zur angezeigten Schätzung dokumentieren. Diese Differenz ist die Zahl, mit der man anschließend plant, nicht die Ausgabe des Werkzeugs.

Redaktionelles Fazit

Sinnvoll ist code2prompt für Teams, die wiederkehrend denselben Repository-Ausschnitt in einen Prompt gießen und das per Template reproduzierbar halten wollen, sowie für Python-Agenten, die die Bindings aus code2prompt-rs nutzen. Wer einen Überblick über ein sehr großes Repository braucht, statt einer vollständigen Textkopie, sollte zuerst prüfen, ob die Token-Schätzung mit --output-format json und einem echten Tokenizer des Zielmodells zusammenpasst. Wer die Lizenz- und Metadaten-Ausgabe des Prompts anpassen muss, prüft vorab die Template-Dateien und die Git-Optionen, weil die Standardausgabe sonst Dateipfade und Git-Metadaten mitliefert, die nicht in jede Weitergabe gehören.

Offizielle Quellen

1. License: MIT
2. mufeedvh/code2prompt on GitHub
3. Project website
4. README
5. Releases