yek: Repository-Dateien für den LLM-Kontext bündeln

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

Ein Sprachmodell sieht nur, was im Prompt steht. Wer ihm ein ganzes Repository vorlegen will, muss hunderte Dateien in einen einzigen Textblock verwandeln, und dabei entscheiden, welche Dateien überhaupt hineingehören und in welcher Reihenfolge sie erscheinen. yek nimmt diese Arbeit ab: Ein Aufruf im Projektverzeichnis erzeugt eine Datei mit allen textbasierten Inhalten, standardmäßig im temporären Verzeichnis, und gibt den Pfad auf der Konsole aus. Die Zielgruppe sind Entwickler, die Prompts für Codeanalyse, Refactoring-Vorschläge oder Fehlersuche zusammenstellen und dafür nicht jedes Mal ein eigenes Skript schreiben wollen. Der Name ist Farsi und bedeutet "eins", was die Funktion recht genau beschreibt.

Sortierung nach Git-Historie statt nach Dateibaum

Der interessanteste Teil von yek ist nicht das Zusammenkopieren, sondern die Reihenfolge. Laut README nutzt das Tool die Git-Historie, um zu erschließen, welche Dateien wichtiger sind, und platziert diese ans Ende der Ausgabe. Die Begründung im README: Modelle schenken Inhalten, die später im Kontext stehen, mehr Aufmerksamkeit. Das ist eine Annahme über Modellverhalten, keine gemessene Eigenschaft, und sie sollte als Designentscheidung gelesen werden, nicht als Garantie. Wer die Reihenfolge nicht will, kann sie über die Konfiguration beeinflussen, denn die Datei erlaubt explizite Prioritätsregeln sowie einen Git-basierten Prioritätsbonus. In einem Repository mit flacher Historie oder einem einzigen großen Commit fällt dieser Mechanismus weitgehend weg, und die Sortierung nähert sich dann einer willkürlichen Reihenfolge an.

Ausschlussregeln: .gitignore, Binärdateien und eigene Muster

Standardmäßig respektiert yek die .gitignore-Regeln des Projekts. Zusätzlich leitet es weitere Ignore-Muster ab, laut README für Binärdateien und große Dateien. Diese eingebaute Liste lässt sich über --unignore-patterns auflösen, falls sie zu aggressiv greift, und über --ignore-patterns erweitern. Die Konfigurationsdatei kennt daneben einen eigenen Schlüssel, um weitere Binär-Endungen zur eingebauten Liste hinzuzufügen. Das ist der Punkt, an dem in der Praxis die meisten Überraschungen entstehen: Wer generierte Artefakte wie Lockfiles, Minified-Bundles oder Datenexporte im Baum hat, muss prüfen, ob sie als Text durchgehen und damit in die Ausgabe rutschen. Das Tool kann nicht wissen, welche Dateien für einen bestimmten Prompt relevant sind. Es wendet Regeln an, und diese Regeln sind die einzige Stellschraube.

Ausgabemodi: Datei, Pipe, Token-Limit

yek erkennt laut README automatisch, ob die Ausgabe in eine Pipe geht, und streamt dann, statt eine Datei zu schreiben. In einem Terminal landet das Ergebnis dagegen in einer temporären Datei, deren Pfad ausgegeben wird. Über --output-dir und --output-name lässt sich das Ziel festlegen. Für Pipelines ist das der nützliche Modus, etwa yek src/ | pbcopy auf macOS. Zwei Limits stehen zur Wahl: --max-size arbeitet in Bytes und ist mit 10MB vorbelegt, --tokens schaltet auf Token-Zählung um und akzeptiert Werte wie 128k. Wenn das Limit greift, entfernt yek Dateien, die nicht mehr hineinpassen, und versucht laut README, wichtigere Dateien zu behalten. Das ist ein Verlustgeschäft mit Ansage: Die Ausgabe ist dann kein vollständiges Abbild des Repositories mehr, und niemand erfährt ohne Weiteres, welche Dateien fehlen. Wer das wissen muss, sollte --debug einsetzen oder den JSON-Modus wählen.

Installation und die ersten Befehle

Auf macOS und Linux installiert das Projekt sich per curl: curl -fsSL https://azimi.me/yek.sh | bash. Unter Windows ist es das PowerShell-Pendant irm https://azimi.me/yek.ps1 | iex. Wer lieber selbst baut, klont das Repository und ruft cargo install --path . im Projektverzeichnis auf. Der einfachste Lauf ist yek ohne Argumente. Mehrere Verzeichnisse lassen sich in einem Aufruf verarbeiten: yek src/ tests/. Einzelne Dateien gehen genauso, und Glob-Muster werden unterstützt, müssen aber in Anführungszeichen stehen, damit die Shell sie nicht vorher auflöst, also etwa yek "src/**/*.ts". Ein begrenzter Lauf sieht so aus: yek --tokens 128k. Wer das Ausgabeverzeichnis kontrollieren will, schreibt yek --max-size 100KB --output-dir /tmp/yek src/. Für eigene Formate dient --output-template mit den Platzhaltern FILE_PATH und FILE_CONTENT; der Standard ist ">>>> FILE_PATH\nFILE_CONTENT". Ein Verzeichnisbaum lässt sich mit -t, --tree-header voranstellen, --tree-only liefert nur den Baum. Beide sind laut Hilfe mit dem JSON-Modus unvereinbar.

yek.yaml: was sich konfigurieren lässt und was nicht

Die Datei yek.yaml liegt im Projektwurzelverzeichnis oder wird über --config-file angegeben. Über --no-config lässt sie sich vollständig übergehen, was für reproduzierbare Läufe in CI nützlich ist. Konfigurierbar sind unter anderem max_size, tokens, ignore_patterns, unignore_patterns, json, debug, die Ausgabedatei und das Ausgabetemplate, dazu Prioritätsregeln und der Git-Prioritätsbonus. Die README-Aufzählung der Optionen ist an dieser Stelle nicht vollständig wiedergegeben, und die Dokumentation der Prioritätsregeln bleibt vage: Es ist nicht beschrieben, welche Syntax eine Regel hat oder wie sich zwei widersprechende Regeln zueinander verhalten. Wer die Sortierung fein steuern will, muss das im Repository selbst nachlesen. Das ist eine echte Lücke, denn die Priorisierung ist das Verkaufsargument des Tools.

Grenzen: kein Ersatz für Kontextauswahl

yek löst ein Transportproblem, kein Relevanzproblem. Es kann nicht beurteilen, ob eine Datei für die gestellte Frage wichtig ist; es wendet Ignore-Muster und einen Git-Bonus an. In einem Monorepo mit mehreren Packages, von denen nur eines bearbeitet werden soll, ist das falsche Werkzeug, denn die Ausgabe zieht weiterhin alles ein, was nicht ignoriert wird. Der zweite wunde Punkt ist die Token-Zählung. Das README nennt keine Methode dahinter, und Token-Anzahl ist modellabhängig. Wer mit --tokens 128k arbeitet, sollte damit rechnen, dass die Zahl nur eine Näherung ist und das Modell trotzdem abschneidet. Drittens: Ohne Git-Historie, etwa in einem ausgepackten Archiv oder einem Verzeichnis, das nie committet wurde, entfällt die Priorisierung, und yek verhält sich wie ein reiner Dateisammler.

Alternative: repomix und der Unterschied im Ansatz

Das naheliegendste andere Werkzeug ist repomix, das dieselbe Aufgabe für LLM-Kontexte übernimmt und ebenfalls Token-Zählung, Ausschlussmuster und mehrere Ausgabeformate bietet. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Gewichtung. repomix legt Wert auf eine breite Formatunterstützung und darauf, die Ausgabe in verschiedene Ökosysteme zu bringen; yek setzt auf die Sortierung nach Git-Historie und darauf, dass die wichtigsten Dateien am Ende stehen. Wenn die eigene Arbeitsweise darin besteht, Prompts aus einem gewachsenen Repository zu bauen, ist yeks Sortierung ein Argument. Wenn die Ausgabe in ein bestimmtes Format oder eine bestimmte Pipeline fließen muss, ist repomix der breitere Weg. Beides sind Annäherungen; keines der beiden Werkzeuge kennt die Frage, die man dem Modell stellen will.

Wartung, Lizenz und Kosten beim Upgrade

yek steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange der Lizenztext und der Urheberrechtshinweis beiliegen. Rechtliche Beratung ist das nicht; wer das Tool in ein Produkt einbettet, sollte die Bedingungen selbst prüfen. Die Release-Historie zeigt drei Veröffentlichungen innerhalb von vier Wochen im Juni 2026, was auf einen aktiven Entwicklungsstand hindeutet, aber auch bedeutet, dass sich CLI-Flags und Konfigurationsschlüssel zwischen Versionen bewegen können. Wer yek in einer Pipeline fest verdrahtet, sollte die Version pinnen, statt die Installationsskripte ungeprüft in einem Build-Schritt auszuführen, denn curl | bash zieht jeweils die aktuelle Fassung. Ein Upgrade ist billig, solange nur Standardoptionen genutzt werden; sobald yek.yaml eigene Prioritätsregeln enthält, ist nach jedem Versionssprung ein Gegenlauf gegen die vorherige Ausgabe sinnvoll, um zu sehen, ob sich die Reihenfolge verschoben hat.

Redaktionelles Fazit

yek passt zu Entwicklern, die aus einem Git-Repository schnell eine einzelne, nach Wichtigkeit sortierte Textdatei für einen LLM-Prompt erzeugen wollen, ohne ein Skript zu schreiben. Wer kein Git-Repository hat oder Dateien außerhalb von Git priorisieren muss, sollte zu einem Werkzeug greifen, das ohne Historie auskommt. Vor dem produktiven Einsatz ist zu klären, ob die eingebauten Ignore-Muster die eigenen generierten Dateien erfassen und ob das Standardlimit von 10MB zum Zielkontext passt, denn beides lässt sich nur über yek.yaml oder die CLI-Flags korrigieren.

Offizielle Quellen

1. Issues
2. License: MIT
3. mohsen1/yek on GitHub
4. README
5. Releases