Ohne Tool: bei jeder Änderung neu suchen.
Deine KI sucht sich die passenden Dateien Stück für Stück zusammen. Beim nächsten Mal fängt sie wieder von vorne an. Das kostet Tokens und damit dein Limit.
GITHUB REPO
Eine Landkarte, damit deine KI nicht jedes Mal neu sucht.
Code Review Graph ist ein kostenloses Open-Source-Tool (MIT). Es baut eine lokale Landkarte deines Codes, damit deine KI bei einer Änderung gezielt die betroffenen Dateien liest statt jedes Mal alles neu zu durchsuchen. Läuft auf deinem Rechner, ohne Telemetrie.
- Code Review Graph
- GitHub
- Fortgeschritten
FEATURES
Was es kann.
Mit Tool: eine lokale Landkarte.
Das Tool merkt sich, welche Teile deiner App zusammenhängen (Aufrufe, Imports, Tests). Es liegt als SQLite-Datei bei dir und hält sich per Hooks aktuell.
Die KI liest nur, was betroffen ist.
Änderst du eine Datei, erkennt das Tool, welche anderen Dateien betroffen sein könnten. Es markiert dabei bewusst eher zu viel als zu wenig. Die KI liest gezielt diese Dateien.
Rund 60-mal weniger Tokens im Benchmark.
Median etwa 63x über 6 Repos (Beispiel Flask: 143.594 auf 2.196 Tokens, 65,4x). Wichtig: Gemessen gegen "den gesamten Code lesen", nicht gegen eine geübte KI-Suche. Deine Ersparnis im Alltag fällt kleiner aus.
Lokal, kostenlos, ohne Telemetrie.
MIT-Lizenz, läuft auf deinem Rechner und telefoniert laut FAQ nicht nach Hause. 32.380 Sterne auf GitHub (Stand 25.10.2026).
USE CASES
Wofür du es einsetzt.
Du baust deine App mit KI und dein Limit ist ständig leer
Je größer die App wird, desto mehr Dateien muss die KI bei jeder Änderung durchsuchen. Die Landkarte spart ihr diesen Weg.
Du willst vor einer Änderung wissen, was daran hängt
Das Tool zeigt dir, welche anderen Teile von einer Änderung betroffen sein könnten, bevor etwas kaputtgeht.
INSTALLATION
Dein Setup zum Kopieren.
pip install code-review-graph code-review-graph install code-review-graph build
MASTER-PROMPT
Dein Auftrag zum Kopieren.
Du richtest code-review-graph in meinem Projekt ein und zeigst mir danach, dass es wirklich wirkt. Arbeite Schritt für Schritt und sag mir nach jedem Schritt in einem Satz, was passiert ist. Schritt 1, lohnt es sich? Zähl die Dateien im Projekt (git ls-files | wc -l). Unter etwa 300 Dateien sag mir ehrlich, dass das Tool laut eigener FAQ hier kaum etwas spart, und frag, ob ich trotzdem weitermachen will. Schritt 2, Voraussetzungen: Prüf, ob Python 3.10 oder neuer da ist. Wenn nicht, sag mir, wie ich es installiere, und stopp. Schritt 3, Installation: pip install code-review-graph (oder pipx install code-review-graph, falls pip nicht global installieren darf) code-review-graph install --platform claude-code Erklär mir kurz, welche Dateien install angelegt hat (MCP-Eintrag, Hooks, Hinweis in der CLAUDE.md). Schritt 4, Karte bauen: code-review-graph build code-review-graph status Nenn mir die Zahl der Nodes, Edges und Files. Steht dort 0, such den Fehler, bevor du weitermachst. Schritt 5, Neustart: Sag mir, dass ich Claude Code jetzt neu starten muss, damit die Karte als MCP-Server geladen wird, und dass ich danach „weiter“ schreiben soll. Stopp hier. Schritt 6, nach dem Neustart: Prüf mit /mcp, ob code-review-graph verbunden ist. Dann beantworte mit der Karte statt mit grep: „Was hängt an der wichtigsten Funktion in diesem Projekt?“ Zeig mir, welches Werkzeug der Karte du benutzt hast. Schritt 7, Beweis: Ändere testweise nichts, sondern führ code-review-graph detect-changes --brief aus und erklär mir das Feld Token Savings in zwei Sätzen. Sag mir dazu ehrlich: Die Ersparnis ist geschätzt und im Vergleich zum Lesen des gesamten Codes gerechnet. Ab jetzt gilt für dieses Projekt: Bevor du bei einer Änderung Dateien suchst, frag zuerst die Karte, welche Dateien betroffen sind, und lies dann gezielt nur diese.
Ich habe gerade [WAS DU GEÄNDERT HAST] geändert. Frag zuerst die code-review-graph-Karte, welche Funktionen, Dateien und Tests davon betroffen sein könnten, und lies nur diese. Sag mir dann in kurzen Punkten: 1. Was könnte durch meine Änderung kaputtgehen? 2. Welche Tests sollte ich laufen lassen? 3. Fehlt irgendwo ein Test? Wenn die Karte veraltet wirkt, führ vorher code-review-graph update --brief aus.
MEINE EINSCHÄTZUNG
Wofür es sich lohnt.
Gut geeignet für
- Alle, die mit KI eine größere App bauen und merken, dass das Limit zu schnell leer ist
- Wer nichts aus dem Projekt in die Cloud schicken will: alles bleibt lokal
Weniger geeignet für
- Bei kleinen Projekten bringt es kaum etwas: Laut FAQ lohnt es sich erst ab ein paar hundert Dateien
- Die rund 60-mal sind gegen "gesamten Code lesen" gemessen, nicht gegen eine geübte KI-Suche. Im Alltag ist die Ersparnis kleiner
Eine Karte, weniger Suchen.
Kostenloses Repo, lokal auf deinem Rechner, drei Befehle zum Start.
FAQ
Häufige Fragen.
Was ist Code Review Graph?
Ein kostenloses Open-Source-Tool (MIT), das eine lokale Landkarte deines Codes baut. Deine KI liest damit gezielt die betroffenen Dateien statt jedes Mal alles neu zu durchsuchen.
Lohnt es sich für kleine Projekte?
Kaum. Laut FAQ im Repo bringt es unter ein paar hundert Dateien wenig.
Stimmt die Zahl "60-mal weniger"?
Sie stammt aus dem Benchmark im README (Median etwa 63x über 6 Repos) und ist gegen "gesamten Code lesen" gemessen. Gegen eine geübte KI-Suche fällt der Vorsprung kleiner aus.
Werden meine Daten irgendwohin geschickt?
Nein. Laut FAQ läuft das Tool lokal und sendet keine Telemetrie.
