repo2txt: Repository-Inhalte als einzelne Textdatei für LLM-Prompts

Welches Problem repo2txt adressiert

Ein Sprachmodell kennt ein Repository nicht. Wer Code in einen Prompt einfügen will, muss vorher entscheiden, welche Dateien relevant sind, sie einlesen und in eine Form bringen, die sich als Textblock einfügen lässt. Genau das automatisiert repo2txt. Die README beschreibt den Zweck als Umwandlung von Repositories in reinen Text für LLM-Prompts und nennt als Zielgruppe AI-gestützte Entwicklung. Das Werkzeug ist also kein Analysewerkzeug und kein Ersatz für eine Entwicklungsumgebung. Es ist ein Vorbereitungsschritt zwischen einem Repository und einem Chat-Fenster. Der Nutzen liegt weniger in der Umwandlung selbst, die sich mit wenigen Zeilen Skript erledigen ließe, sondern in der Auswahl: Verzeichnisse abwählen, Dateitypen abwählen, Ignore-Muster setzen und dabei sehen, wie viele Tokens die Auswahl kostet. Wer schon einmal ein halbes Repository in einen Prompt kopiert und die Kontextgrenze gerissen hat, kennt den Bedarf.

Wie die Umwandlung im Browser abläuft

Die Verarbeitung findet laut README vollständig im Browser statt. Es gibt keinen Server, der den Code sieht, und laut README auch kein Tracking. Für GitHub-Repositories liest die Anwendung die Dateien über die GitHub-Schnittstelle; ein persönlicher Token erhöht dabei das Ratenlimit von 60 auf 5000 Anfragen pro Stunde und schaltet private Repositories frei. Der Token wird laut README ausschließlich im sessionStorage gehalten, verschwindet also mit dem Schließen des Tabs. Für lokale Quellen nutzt die Anwendung den Verzeichnisauswahldialog des Browsers oder liest eine hochgeladene Zip-Datei über JSZip. Die Token-Zählung läuft über gpt-tokenizer und wird laut README in Web Workers ausgeführt, damit die Oberfläche bei großen Auswahlen nicht blockiert. Die Dateiliste wird mit TanStack Virtual dargestellt, was den Umgang mit sehr vielen Dateien ermöglichen soll. Die Anbieter für GitHub, GitLab, Azure DevOps und lokale Quellen sind getrennt geladen, um die anfängliche Bundle-Größe zu drücken. Bemerkenswert ist die Reihenfolge des Datenflusses: erst auswählen, dann zählen, dann erzeugen. Die Token-Zahl ist damit Teil der Auswahlentscheidung und nicht ein Ergebnis, das man hinterher zur Kenntnis nimmt.

Installation und die tatsächlich relevanten Optionen

Der schnellste Weg ist die gehostete Instanz unter abinthomas.in/repo2txt. Wer lokal arbeiten will, klont das Repository und startet den Entwicklungsserver. Die README nennt diese Befehle: git clone https://github.com/abinthomasonline/repo2txt.git, dann cd repo2txt, npm install und npm run dev, woraufhin die Anwendung unter http://localhost:5173/repo2txt/ erreichbar ist. Für einen Produktionsbuild steht npm run build bereit, die Ausgabe landet in ./dist. Für Tests nennt die README npm run test:unit und npm run test:e2e, wobei Vitest und Playwright im Technologie-Stack auftauchen. Als Konfigurationsoberfläche dient die Weboberfläche selbst: Anbieter umschalten, Repository-URL einfügen, optional den Token setzen, Dateien über den Baum oder über Erweiterungsfilter auswählen und schließlich Generate Output auslösen. Die Ausgabe lässt sich in die Zwischenablage kopieren oder als .txt herunterladen. Die README listet unterstützte URL-Formate auf, darunter https://github.com/owner/repo, Pfade mit /tree/branch-name und verschachtelte Pfade bis zu einem Unterordner. Auch Branchnamen mit Schrägstrichen sollen funktionieren.

Filterung als eigentliche Stärke und als Fehlerquelle

Die Auswahlmechanik ist der Teil, der repo2txt von einem Einzeiler unterscheidet. Man kann nach Dateiendung ein- und ausschalten, .gitignore-Muster sollen automatisch berücksichtigt werden, eigene Ignore-Muster lassen sich ergänzen, und einzelne Verzeichnisse können gezielt gewählt werden. Ein Dateibaum mit virtueller Darstellung zeigt die Struktur. Das ist praktisch, hat aber eine Grenze: Die Filterlogik bestimmt, was im Prompt landet, und ein falsch gesetztes Muster entfernt stillschweigend Kontext. Wer etwa versehentlich alle .json-Dateien abwählt, verliert package.json und damit die Abhängigkeitsliste, ohne dass die Oberfläche das als Warnung behandelt. Die Token-Zahl pro Datei und insgesamt hilft, den Umfang einzuschätzen, sie sagt aber nichts über inhaltliche Relevanz. Die README führt GitLab und Azure DevOps ausdrücklich als Beta, entsprechend ist dort mit Einschränkungen zu rechnen. Wer diese beiden Quellen produktiv nutzen will, sollte sie vorher an einem bekannten Repository gegen die Weboberfläche prüfen.

Grenzen und Fälle, in denen das Werkzeug ungeeignet ist

Die README verspricht den Umgang mit Repositorys von über 10.000 Dateien. Das ist eine Aussage über die Oberfläche, nicht über die Brauchbarkeit der Ausgabe. Ein Sprachmodell hat eine Kontextgrenze, und eine Textdatei mit zehntausend Dateien passt in keinen gängigen Kontext. Die Token-Zählung über gpt-tokenizer ist zudem modellspezifisch: Sie bildet die Zerlegung eines GPT-Tokenizers ab, nicht die eines beliebigen anderen Modells. Wer mit einem anderen Anbieter arbeitet, bekommt eine Näherung, die je nach Modell mehr oder weniger stark abweicht. Ein weiterer Punkt ist die Wiederholbarkeit. Die Auswahl entsteht in der Oberfläche, es gibt laut README keine Konfigurationsdatei, die man einchecken könnte. Wer denselben Ausschnitt später erneut erzeugen will, muss die Auswahl manuell nachbauen. Für einmalige Prompt-Vorbereitung ist das unerheblich, für einen wiederkehrenden Ablauf in einer Pipeline ist es ein Ausschlusskriterium. Auch die Aktualität ist begrenzt: Die Anwendung liest beim Laden, nicht fortlaufend. Bei einem Repository, das sich während der Sitzung ändert, arbeitet man mit einem Schnappschuss.

Alternative: eigene Skripte gegen die Plattform-API

Der naheliegende Vergleich ist ein eigenes Skript, das die GitHub-API oder einen lokalen Klon durchläuft, Dateien nach Endung filtert und mit Trennmarkierungen in eine Datei schreibt. Der Unterschied liegt nicht in der Ausgabe, die ähnlich aussehen wird, sondern in der Steuerung. Ein Skript lässt sich versionieren, in einer CI ausführen und mit festen Regeln reproduzieren. repo2txt bietet dafür eine visuelle Auswahl und eine sofortige Token-Schätzung, die man in einem Skript erst nachbauen müsste. Der zweite Unterschied ist die Vertrauensgrenze. Ein Skript läuft dort, wo man es startet, und kann mit einem Token umgehen, das in einer Umgebungsvariable liegt. repo2txt hält den Token laut README nur im sessionStorage und verarbeitet alles im Browser, was für gelegentliche Nutzung auf einem fremden Rechner bequemer ist. Wer regelmäßig dieselbe Teilmenge eines großen Repositorys braucht, ist mit einem Skript besser bedient. Wer spontan und ohne Terminal arbeiten will, mit repo2txt.

Wartung, Abhängigkeiten und die Lizenzfrage

Der Technologie-Stack ist aktuell gehalten: React 19, Vite 5, Tailwind CSS 3, Zustand, JSZip, gpt-tokenizer, TanStack Virtual, Vitest und Playwright. Das bedeutet eine ganze Kette von Abhängigkeiten, die mit der Zeit gepflegt werden muss. Wer die Anwendung selbst hostet, übernimmt diese Pflege. Wer die gehostete Instanz nutzt, ist von deren Verfügbarkeit abhängig. Der letzte Push liegt laut Repository-Angaben im August 2026, das Projekt ist nicht archiviert, und es wurden keine Releases abgerufen. Ohne Releases gibt es keine Versionsnummern, an denen man sich orientieren könnte, was die Frage nach Änderungen zwischen zwei Ständen erschwert. Bei der Lizenz widersprechen sich die Angaben: Die README trägt ein MIT-Badge und verweist auf eine LICENSE-Datei, die Metadaten des Repositorys enthalten jedoch keine Lizenzangabe. Das ist kein juristischer Rat, aber ein Punkt, der vor einer Übernahme in eigene Abläufe oder einer Weiterverbreitung geklärt werden sollte. Ein Blick in das Repository selbst, nicht in die README, ist dafür der erste Schritt.

Redaktionelles Fazit

Sinnvoll ist repo2txt für Entwickler, die gelegentlich ein Repository als Kontext in ein Chat-Modell einfügen wollen und dafür keine Server-Komponente betreiben möchten. Wer große Monorepos regelmäßig verarbeitet oder reproduzierbare Pipelines braucht, sollte zuerst den Token-Zähler an einem echten Ziel-Repository prüfen, bevor er sich auf die Ausgabe verlässt. Ungeklärt ist die Lizenzfrage: Das Repository gibt keine Lizenzdatei an, während die README MIT nennt. Das ist vor einer Übernahme in eigene Abläufe zu klären.

Offizielle Quellen

1. abinthomasonline/repo2txt on GitHub
2. Issues
3. Project website
4. README