Ein KI-Agent kann Code erzeugen. Ein belastbarer Entwicklungsablauf braucht mehr: eine Reihenfolge, Prüfungen und klare Zuständigkeiten. Genau dort setzt ECC an. Das Open-Source-Projekt bündelt Agenten, Skills, Regeln und Sicherheitsprüfungen für Claude Code und weitere Code-Editoren.
was ECC im Kern macht
ECC ist kein einzelner Befehl, der ein Projekt automatisch besser macht. Es ist ein Baukasten für wiederkehrende Entwicklungsarbeit: Anforderungen strukturieren, Änderungen umsetzen, Tests ausführen, einen frischen Review-Blick einholen und Ergebnisse festhalten. Das Projekt nennt für die aktuelle Plugin-Version 68 Agenten, 292 Skills und 94 Kompatibilitätsbefehle. Diese Zahlen beschreiben den Umfang, nicht den empfohlenen Startpunkt.
Für ein Team zählt eine einfachere Frage: Wo geht Arbeit heute verloren? Bei unklaren Anforderungen, fehlenden Tests, oberflächlichen Reviews oder bei Sicherheitsprüfungen, die erst kurz vor dem Release auffallen? Erst wenn die Engstelle klar ist, lohnt sich eine passende Erweiterung.
vier Sätze für den Alltag
Im Alltag lässt sich der Umfang auf vier verständliche Schritte reduzieren: planen, bauen, sichern und testen. Planung hält Ziel, Auswirkungen und Prüfkriterien vor dem ersten Edit fest. Beim Bauen bleibt die Änderung klein und überprüfbar. Sicherheit bedeutet, Änderungen und Konfigurationen gezielt zu hinterfragen. Tests liefern den Nachweis, dass das Gewünschte funktioniert und ein absichtlich kaputtgemachter Fall nicht unbemerkt bleibt.
Das ist keine neue Methode. Der Vorteil liegt darin, dass der Ablauf im Arbeitswerkzeug greifbar wird. Ein Agent kann bei einer klar abgegrenzten Aufgabe unterstützen. Er ersetzt aber weder die Entscheidung über den Umfang noch die Verantwortung für einen Release.
Prompt-Vorlagen zum Kopieren
Ein guter Auftrag an einen Coding-Agenten beginnt nicht mit „mach das besser“. Er nennt das Ergebnis, die Grenzen und den Nachweis. So kann der Agent entscheiden, welche der vorhandenen Fähigkeiten tatsächlich passen. Die folgenden Vorlagen sind absichtlich knapp. Ersetze nur die eckigen Klammern und streiche alles, was für deine Aufgabe nicht gilt.
1. Erst planen, noch nichts ändern
Plane diese Änderung: [Ziel in einem Satz].
Untersuche zuerst den bestehenden Ablauf und nenne die betroffenen Dateien.
Definiere maximal fünf Arbeitsschritte mit je einem Prüfkriterium.
Nenne Risiken, offene Annahmen und einen Rückweg.
Schreibe noch keinen Code und ändere keine Dateien.
Dieser Prompt verhindert den häufigsten Fehlstart: Der Agent springt direkt in eine Lösung, bevor klar ist, woran die Änderung hängt. Besonders bei Login, Zahlungen, Datenmigrationen oder Schnittstellen sollte der Plan vor der ersten Zeile Code stehen.
2. Einen bestätigten Plan umsetzen
Setze den bestätigten Plan für [Ziel] um.
Arbeite nur in diesen Dateien oder Modulen: [Scope].
Halte die Änderung klein und passe bestehenden Stil an.
Schreibe oder ergänze Tests für das gewünschte Verhalten.
Führe danach [Prüfbefehl] aus und nenne geänderte Dateien,
Testergebnis und offene Risiken. Kein Commit, kein Deploy.
Der Scope-Satz schützt vor freundlichem Übergreifen. Ein Agent sieht oft Verbesserungspotenzial außerhalb des Auftrags. Das kann richtig sein, ist aber eine eigene Entscheidung. Mit dem klaren Umfang bleibt nachvollziehbar, welche Änderung zu welchem Ergebnis gehört.
3. Sicherheitsprüfung ohne automatische Änderungen
Prüfe [Datei, Diff oder Bereich] auf echte Sicherheitsrisiken.
Betrachte Eingaben, Berechtigungen, Geheimnisse, externe URLs,
Redirects und Datenzugriffe. Liste nur Befunde mit Datei, Zeile,
Auswirkung und begrenztem Fix. Keine Stilhinweise.
Ändere nichts, führe keine produktionsnahen Aktionen aus.
„Echte Risiken“ ist wichtig. Eine lange Liste theoretischer Hinweise hilft niemandem. Ein brauchbarer Befund zeigt die konkrete Stelle, erklärt den Schaden und lässt sich mit einer kleinen Änderung prüfen. Für sehr kritische Bereiche bleibt eine unabhängige zweite Prüfung sinnvoll.
4. Abnahme mit Gegenprobe
Prüfe die Umsetzung von [Ziel] gegen diese Kriterien:
[Kriterium 1]
[Kriterium 2]
[Kriterium 3]
Führe die passenden Tests und eine Gegenprobe aus: Verändere einen
relevanten Testfall kurz so, dass er fehlschlagen muss, nimm die Änderung
zurück und prüfe erneut. Melde nur belegte Ergebnisse und offene Punkte.
Die Gegenprobe beantwortet eine unbequeme, aber zentrale Frage: Prüft der grüne Test wirklich das Richtige? Wenn ein absichtlich kaputtgemachter Fall weiterhin grün bleibt, ist der Nachweis wertlos. Diese Schleife dauert wenig länger als ein bloßer Testlauf und verhindert viel Scheinsicherheit.
5. Ein Team-Übergabeprompt
Erstelle eine Übergabe für [Empfänger oder nächstes Team].
Enthalten sein müssen: Ziel, tatsächlicher Scope, geänderte Dateien,
ausgeführte Prüfungen mit Ergebnis, nicht geprüfte Punkte, bekannte Risiken
und der konkrete nächste Schritt. Keine Annahmen als Fakten darstellen.
Damit wird aus dem Ergebnis eines Agenten eine nutzbare Arbeitsgrundlage. Gerade bei längeren Vorhaben ist die Übergabe wichtiger als ein langer Chat-Verlauf: Sie trennt bestätigte Fakten von offenen Punkten und macht den nächsten Schritt ohne Rätselraten möglich.
sauber installieren
Die offizielle Dokumentation nennt zwei Wege für Claude Code. Entweder wird das Plugin direkt im Claude-Code-Chat eingebunden:
/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc
Oder das geführte Setup wird im Terminal gestartet:
npx [email protected] setup
Beide Wege installieren dieselbe Erweiterung. Deshalb gilt: einen Weg wählen, nicht übereinander installieren. Wer noch die frühere Bezeichnung everything-claude-code nutzt, sollte erst die Migrationshinweise lesen. Die aktuelle Plugin-ID lautet ecc@ecc.
Regelpakete sind ein separater Schritt. Claude-Code-Plugins können sie nicht automatisch mitliefern. Starte mit den gemeinsamen Regeln und genau einer Sprache oder einem Stack. Ein kompletter Regelordner für jede denkbare Technologie macht die Umgebung schwerer, nicht besser.
wo der Rahmen liegt
Viele Agenten bedeuten nicht, dass jede Aufgabe delegiert werden sollte. Für eine kleine Änderung genügt häufig ein klarer Test und ein Review. Für eine größere Funktion helfen Planung, Umsetzung und eine unabhängige Gegenprüfung. Die richtige Anzahl ist die, die ein konkretes Risiko abdeckt, ohne eine zweite, undurchsichtige Prozessschicht zu schaffen.
Besonders sensibel sind Hooks, MCP-Server und Projektanweisungen. Sie können Befehle ausführen, Zugänge halten oder die Arbeitsweise des Agenten prägen. Behandle sie deshalb wie Code: Quelle prüfen, Berechtigung klein halten, Wirkung testen und einen Weg zurück vorsehen.
mein Startpunkt
Ich würde ECC nicht mit einem großen Agenten-Katalog beginnen. Sinnvoller ist ein Testprojekt mit einem wiederkehrenden Ablauf: eine kleine Aufgabe planen, mit einem klaren Prüfbefehl umsetzen, anschließend reviewen und das Ergebnis dokumentieren. Erst wenn dieser Durchlauf stabil ist, kommen zusätzliche Regeln oder spezialisierte Agenten dazu.
So bleibt der Nutzen sichtbar. Das System hilft dort, wo es Reibung reduziert, statt zur neuen Aufgabe neben der eigentlichen Produktarbeit zu werden.
der Kern in drei Sätzen
ECC bündelt Werkzeuge für einen nachvollziehbaren KI-gestützten Entwicklungsablauf. Der richtige Einstieg ist nicht die maximale Zahl an Agenten, sondern eine klar benannte Lücke im eigenen Prozess. Installationen und Konfigurationen verdienen denselben Sicherheitsblick wie der Code, den sie beeinflussen.
häufige Fragen
Was ist ECC für Claude Code?
ECC ist ein Open-Source-Plugin für KI-gestützte Entwicklungsumgebungen. Es bündelt spezialisierte Agenten, Skills, Regeln und Prüfabläufe, damit Planung, Umsetzung, Review und Verifikation klarer zusammenarbeiten.
Wie installiere ich ECC in Claude Code?
Der offizielle Weg führt entweder über das Plugin ecc@ecc oder über das geführte Paket ecc-universal. Beide Wege installieren dieselbe Erweiterung. Man sollte einen Weg wählen und keine parallele manuelle Installation darüberlegen.
Braucht jedes Projekt alle ECC-Agenten?
Nein. Der Nutzen entsteht nicht durch möglichst viele Agenten. Ein kleines Team sollte mit einem klaren Ablauf und wenigen passenden Regeln beginnen und Erweiterungen erst hinzufügen, wenn eine wiederkehrende Lücke sichtbar ist.
Was ist bei der Installation besonders wichtig?
Installiert werden sollte ausschließlich aus den vom Projekt genannten offiziellen Quellen. Hooks, MCP-Server und Projektanweisungen sind ausführbare Konfiguration und verdienen deshalb dieselbe Prüfung wie anderer Code.
quellen und Stand
Stand: 07.10.2026. Quelle: ECC auf GitHub, README, Plugin-Metadaten und Migrationshinweise, gelesen am 07.10.2026. ECC entwickelt sich aktiv weiter; Versionsnummern, Umfang und Installationsschritte können sich ändern.


