vlm-code-context-mcp

Ein vollständiges KI-Entwicklungsteam. Ein npm-Paket. Null Kontext-Verschwendung.

📖 Erste Schritte — Neu hier? Hier anfangen!

Product Owner. Architekt. QA. Sicherheit. Zwei Entwickler. Ein Scrum Master. Ein Manager. Ein Lead Dev. Alle führen echte Sprints durch. Alle kommunizieren mit Ihrer Codebasis. Alles in einer einzigen SQLite-Datenbank.

npm install vlm-code-context-mcp
npx code-context-mcp setup .
npx code-context-dashboard ./context.db

Warum gibt es das?

Jedes KI-Coding-Tool stößt auf dasselbe Problem: Das Modell verbraucht sein Kontextfenster allein durch das Lesen Ihrer Codebasis, bevor es etwas Nützliches tun kann. Dann endet die Sitzung, und beim nächsten Mal beginnt alles von vorn.

Das zweite Problem ist noch schlimmer — es gibt keinen Prozess. Sie erhalten eine fähige KI, die keine Ahnung hat, was sie bauen soll, in welcher Reihenfolge oder warum.

vlm-code-context-mcp löst beides. Es indiziert Ihr gesamtes Projekt vorab in einer strukturierten SQLite-Datenbank, sodass Agenten Metadaten anstelle von Rohquellcode abfragen — 25x weniger Token, 26x weniger Daten bei einer Codebasis mit 224 Dateien. Und es verpackt diese Intelligenz in ein vollständiges virtuelles Scrum-Team, das echte Sprint-Zeremonien über 81 MCP-Tools durchführt, mit Phasen-Gates, Retrospektiven, Velocity-Tracking und einem Live-React-Dashboard.

Dies ist kein Aufgaben-Tracker mit aufgesetztem Claude. Es ist ein Betriebssystem für KI-gestützte Entwicklung.

Was Sie in 60 Sekunden erhalten

Step 1/4 — Indexing files into context.db...
  Indexed 25 files, 142 exports, 87 dependencies

Step 2/4 — Loading scrum schema...
  Created 10 scrum tables

Step 3/4 — Importing team from .claude/agents/...
  Loaded 9 agents, 3 sprints, 24 tickets

Step 4/4 — Writing .mcp.json...
  Configured MCP server entry

=== Setup complete! (my-project) ===

Öffnen Sie dann das Dashboard:

npx code-context-dashboard ./context.db
# Opens at http://localhost:3333

Das ist alles. Ihr KI-Team ist bereit. Keine API-Schlüssel. Keine externen Dienste. Keine Cloud-Abhängigkeit. Alles lebt in context.db.

Das Team

Jeder Agent hat eine definierte Rolle, einen System-Prompt, auf seine Verantwortlichkeiten beschränkten Tool-Zugriff und einen Stimmungs-Score, der aus der Ticket-Auslastung und der Retro-Stimmung abgeleitet wird. Das System verfolgt Burnout-Signale über Sprints hinweg.

Der Sprint-Prozess

Sprints laufen durch 10 erzwungene Phasen mit automatisierten Gate-Prüfungen:

preparation → kickoff → planning → implementation → qa → refactoring → retro → review → closed → rest

Gates sind real. Der Sprint rückt nicht in die QA vor, bis Tickets zugewiesen und geschätzt sind. Er wird nicht geschlossen, bis Retro-Ergebnisse protokolliert sind. Die Velocity wird automatisch über jeden Sprint hinweg verfolgt und im Dashboard angezeigt.

Das Dashboard

6 Seiten. 68 Komponenten. Live SSE-Updates.

Jede Mutation — Statusänderung eines Tickets, Stimmungs-Update eines Agenten, Sprint-Phasenübergang — löst eine sofortige Dashboard-Aktualisierung über SQLite WAL-Überwachung aus. Kein Polling. Kein manuelles Aktualisieren.

• Sprint Board — Kanban, Planungsansicht, QA-Gate-Tracker, Burndown-Chart

• Code Explorer — Dateibaum, Abhängigkeitsgraph, Export/Import-Karte, Änderungshistorie

• Projektmanagement — Gantt-Zeitplan, Meilenstein-Tracker, Discovery-Pipeline, Vision-Editor

• Team — Agenten-Gesundheitskarten, Stimmungstrends, Arbeitslastverteilung

• Retro — Ergebnisse nach Kategorie, Sprint-übergreifende Musteranalyse, Aktionsverfolgung

• Marketing — Release-Notes, Positionierung, Remotion-Vision-Animation

📸 [Screenshot hier]
📸 [Screenshot hier]

Die Bridge-Schicht

Das schwierigste Problem bei agentischen Tools ist die bidirektionale Kommunikation — die UI und die KI dazu zu bringen, in Echtzeit miteinander zu sprechen.

src/bridge/ implementiert einen PreToolUse-Hook, der Claude Code mit dem Dashboard verbindet. In der UI in die Warteschlange gestellte Aktionen werden von der laufenden Claude Code-Sitzung verarbeitet. Das ist es, was das Team lebendig wirken lässt, anstatt wie ein statisches Board.

Dies wird derzeit noch gehärtet. PRs sind willkommen.

Kontext-Effizienz

Gemessen an der eigenen Codebasis dieses Projekts (224 Dateien, 54K Zeilen, 2,1 MB):

Methodik: Aufgabe "Funktion verstehen und ändern" — Auffinden relevanter Dateien, Verständnis von Exporten/Importen/Abhängigkeiten, Überprüfung aktueller Änderungen. Ohne MCP liest der Agent ~20 Rohdateien (durchschnittlich 9.200 Zeichen pro Datei). Mit MCP fragt er strukturierte Metadaten über search_files, find_symbol und get_file_context ab — Zusammenfassungen, Exportlisten und Abhängigkeitsgraphen anstelle von Rohquellcode.

Der erste Index kostet mehr — Dateien müssen gelesen werden, um Metadaten zu generieren. Jede nachfolgende Abfrage ist 25x günstiger. Break-even nach 1 Nutzung. Einsparungen skalieren mit der Größe der Codebasis: Ein Projekt mit 25 Dateien sieht eine 3x Reduzierung, dieses Projekt mit 224 Dateien sieht eine 25x Reduzierung.

Auf einen Blick

Projekthistorie

Komplett durch den eigenen Scrum-Prozess aufgebaut. Das virtuelle Team hat 22 Meilensteine, 69 produktive Sprints und 211 Tickets mit insgesamt 534 Story Points bei einer rollierenden Velocity von ~20 Pkt/Sprint abgeschlossen.

Retro-Ergebnisse über 19 Sprints

Was gut lief (Top-Muster):

• Discovery-First-Ansatz eliminierte konsequent verschwendete Implementierung. Das Ausprobieren von 3-4 Ansätzen vor dem Schreiben von Code sparte Tage an Nacharbeit (S59, S65, S68).

• Parallele Agentenausführung verkürzte die Implementierungszeit drastisch. 4 Agenten arbeiteten gleichzeitig an unabhängigen Tickets, während der Haupt-Thread koordinierte (S59, S65, S67).

• Research-Before-Code erkannte Sackgassen frühzeitig. S68 eliminierte 3 Kandidaten-Bridge-Ansätze (Named Pipes, Unix-Sockets, MCP-Ressourcen-Abonnements) in Stunden statt Tagen.

• Schema-Migrationsmuster (schema_versions-Tabelle) machte inkrementelle DB-Änderungen sicher und wiederholbar. Null Regressionen bei 7 Schema-Erweiterungen (S53, S55).

• Sicherheits-Audit parallel fand 2 HOHE Befunde, bevor Code ausgeliefert wurde (S68). Audits parallel zur Implementierung durchzuführen, nicht danach, ist das richtige Muster.

Was schief lief (Top-Muster):

• Tests als ERLEDIGT markiert, ohne sie auszuführen. Agenten schrieben Tests, konnten sie aber nicht ausführen — die Build-Verifizierung muss erfolgen, bevor ERLEDIGT markiert wird (S61, S65, S66).

• Vorhandene Testfehler erzeugten Rauschen, das echte Regressionen maskierte. Veraltete Tests von alten Schema-Änderungen tauchten immer wieder auf (S53, S67, S68).

• Discovery-Velocity war irreführend. S56 hatte 46sp zugesagt, aber alle Tickets waren nur Dokumentation. Discovery-Punkte sollten getrennt von der Implementierung verfolgt werden.

• Generische Ticket-Titel ohne Beschreibungen oder Akzeptanzkriterien machten QA unmöglich. Jedes Ticket benötigt einen konkreten Umfang (S53).

• Frontend-Technikschulden akkumuliert — 800+ Zeilen Komponenten, 850+ Inline-Styles, null Tests. Hätte früher angegangen werden sollen (S59).

Als nächstes versuchen (Top-Aktionspunkte):

• npm run build ausführen, nachdem jeder Agent fertig ist, bevor das Ticket als ERLEDIGT markiert wird (S65, S66, S67).

• Akzeptanzkriterien zu jedem Ticket bei der Erstellung hinzufügen (S55).

• Aktuellen Status überprüfen, bevor Fix-Tickets erstellt werden — einige waren bereits gelöst (S58).

• Jedes neue Write-MCP-Tool muss eine SSE-Benachrichtigung auslösen — als Checklistenpunkt hinzufügen (S53).

• Kanäle für echtes Push-basiertes Bridge-Signaling implementieren, sobald die API stabil ist (S68).

• Discovery-Punkte getrennt von der Implementierungs-Velocity verfolgen (S56).