Everything Claude Code (ECC): Das Open-Source-Agentenframework für Claude Code

Seit es Coding-Agents gibt: Wie oft hast du zu Beginn jeder Session wieder deinen Stack, eure Konventionen, Präferenzen und Review-Standards erklärt?

Das Problem: Jede neue Unterhaltung startet bei null. Tools wie Claude Code können zwar Code schreiben, aber sie wissen nicht, wie dein Team Code schreibt. Was als Zeitersparnis gedacht war, endet in Handarbeit: immer wieder denselben Projektkontext einfügen, das Modell korrigieren, wenn es abschweift, Anweisungen nachschärfen und jedes Mal dieselben generischen Vorschläge prüfen.

Everything Claude Code (ECC) ist ein Open-Source-Framework, das genau das beheben soll. Trotz des Namens ist es nicht mit Anthropic verbunden. Es ist ein Agentensystem und eine Workflowschicht, die auf Claude Code aufsetzt (kein Modell, keine IDE) und einen generischen Coding-Agenten in eine spezialisierte Engineering-Plattform verwandelt, die deine Standards bereits kennt.

In diesem Artikel zeige ich, was ECC ist, wie die Bausteine zusammenspielen, wie du es installierst und für wen es sich wirklich lohnt.

Aber was ist Claude Code genau? Melde dich zu unserem Claude Code 101 Kurs an und lerne, wie du es in deinen täglichen Entwicklungs-Workflows einsetzt.

Was ist Everything Claude Code?

ECC ist ein Open-Source-Repo, das Claude Code mit einer vorgefertigten Betriebsschicht für Engineering-Arbeit umhüllt.

Du findest das Projekt unter affaan-m/ECC auf GitHub. Es steht unter MIT-Lizenz, wird von Affaan Mustafa gepflegt und basiert auf 10+ Monaten täglicher Claude-Code-Nutzung in echten Produkten. Trotz des Namens besteht keine Verbindung zu Anthropic.

Das Repo bündelt vier Bereiche in einer Installation:

• Ein Agenten-Harness: eine Reihe spezialisierter Sub-Agents (Planner, Architect, Code Reviewer, Security Reviewer, Build-Error-Resolver und viele mehr), an die Claude Code delegiert, statt alles in einem Kontextfenster zu erledigen.
• Ein Skill-Ökosystem: ein paar hundert kleine Workflow-Definitionen für TDD, Security Reviews, Framework-Patterns (Django, Spring Boot, Next.js u. a.), sprachspezifische Codestandards und ML-Engineering-Aufgaben.
• Ein Workflow-Framework: Hooks, die auf Tool-Events laufen, Regeln, die immer gelten, MCP-Server-Configs und Sitzungs-Memory, das über Konversationen hinweg bestehen bleibt.
• Eine Befehls-Ebene: gepflegte Slash-Commands für gängige Workflows plus ein kompatibles Shim-Verzeichnis für ältere Befehlsnamen.

Wichtig: Claude Code bleibt der Motor. Es liest den Code und führt die Tools aus.

ECC kümmert sich um alles drumherum: Welcher Sub-Agent übernimmt diese Aufgabe, welche Schritte der Workflow vorsieht, welche Konventionen dein Stack nutzt und welcher Kontext von der gestrigen Session mitkommen soll.

In der Praxis bedeutet das: Du musst Claude Code nicht mehr für jedes Projekt neu konfigurieren. Du installierst ECC einmal, kopierst die Regelpakete für deinen Stack – und hast eine spezialisierte Engineering-Plattform, die weiß, wie es weitergeht.

Warum Everything Claude Code so populär wurde

Das Wachstum begann mit einem X-Thread.

Anfang 2026 veröffentlichte Mustafa The Shorthand Guide to Everything Claude Code. Innerhalb weniger Tage gab es über 10.000 Lesezeichen. Dann machte er das Repo Open Source – inzwischen hat ECC über 200.000 Stars und 34+ Forks.

Dafür gibt es gute Gründe:

• Agentisches Coding ist Alltag geworden: Mit der breiteren Nutzung von Claude Code wurden die Grenzen des Standard-Setups sichtbar. Was Entwickler brauchten, war eine vorkonfigurierte Schicht, die Kaltstarts, inkonsistente Review-Ergebnisse und Ähnliches eliminiert.
• Gute Agent-Prompts zu schreiben ist schwerer als gedacht: Ein sauberes TDD-Workflow-Design oder ein Code-Reviewer-Prompt mit Confidence-Filter braucht Iteration. Viele Teams wollen das nicht bei jedem Modellwechsel neu bauen und pflegen – getestete Vorlagen wiederzuverwenden ist einfacher.
• Beiträge summierten sich: 270+ Contributor haben Sprachregelpakete (Java, Kotlin, Rust, Perl, PHP), Framework-Support (Quarkus, Laravel), Übersetzungen, IDE-Integrationen jenseits von Claude Code (Cursor, OpenCode, Zed) und Skills beigesteuert.
• Spezialisierung ohne Fine-Tuning: Modelle auf Teamkonventionen zu finetunen ist meist unpraktisch. Eine strukturierte Menge an Skills und Agents zur Laufzeit kommt nah an denselben Effekt heran – und ECC ist einer der vollständigsten Ansätze, das zu verpacken.

Es begann also als X-Thread und entwickelte von dort eine Eigendynamik.

Wie Everything Claude Code funktioniert

ECC ist ein geschichtetes System.

Zwischen dir und deiner Codebasis liegen fünf Komponenten. Claude Code ist die Laufzeit. Skills, Agents, MCP und eine Memory-Schicht umhüllen sie. Jedes Teil erfüllt einen Job und übergibt während der Session Arbeit an die anderen.

Claude Code

Claude Code ist die zugrunde liegende Modell-Schnittstelle.

Es ist die offizielle CLI von Anthropic, um Claude als Coding-Agent zu betreiben. Es liest Dateien, schreibt Diffs, führt Shell-Kommandos aus, ruft Tools auf und hält die Unterhaltung. ECC ersetzt davon nichts. Alles, was ECC hinzufügt, wird zu Sitzungsbeginn in Claude Code geladen und läuft über dessen Plugin-, Hook- und Command-System.

Skills

Skills sind wiederverwendbare Workflow-Anweisungen in Markdown-Dateien.

Jeder Skill ist ein kleines Verzeichnis mit einer SKILL.md, die Claude Code sagt, wie ein bestimmter Aufgabentyp zu handhaben ist. Der Skill benennt Beschreibung, Schritte, erwartete Ausgabe und Constraints. ECC hat rund 260 Skills zu Sprachmustern, Test-Workflows, Framework-Konventionen, ML-Engineering und operativen Tasks.

Wichtig: Du führst Skills nicht manuell aus. Claude Code wählt sie anhand dessen, was du tust – oder du verweist im Prompt darauf.

Agents

Agents sind spezialisierte Sub-Agents, an die Claude Code delegiert.

Jeder ist in Markdown mit Name, Beschreibung, Tool-Allowlist und einem System-Prompt definiert, der das Verhalten eingrenzt. Der code-reviewer liest nur Dateien und meldet Findings. Der planner schreibt Implementierungs-Blueprints, bevor Code angefasst wird. Du siehst das Prinzip.

Der Sinn dieser Aufteilung ist Kontextisolation. Jeder Sub-Agent bekommt für seine Aufgabe ein frisches Kontextfenster, damit die Hauptsession nicht vollläuft. Der Hauptagent koordiniert, die Sub-Agents führen aus.

MCP-Integrationen

MCP (Model Context Protocol) ist die Schnittstelle, über die Claude Code mit externen Tools und Datenquellen spricht.

ECC liefert Konfigurationen für Verbindungen zu GitHub, Supabase, Vercel, Railway und anderen über MCP-Server. Jeder Server stellt Tools bereit, die Claude Code mitten in der Session aufrufen kann. ECC bringt funktionierende Konfigs und Sicherheitsregeln dafür mit.

Standardmäßig aktiviert ECC genau einen Connector (chrome-devtools). Alles andere ist Opt-in – so vermeidest du Tool-Namenskonflikte und hältst die Angriffsfläche klein.

Memory-Schicht

Die Memory-Schicht macht ECC zwischen Sessions zustandsbehaftet.

Hooks laufen beim Stop-Event jeder Unterhaltung und schreiben eine Sitzungszusammenfassung nach ~/.claude/sessions/. Die nächste Session lädt über einen SessionStart-Hook relevanten Kontext zu Beginn. Skills, die das Modell aus deinen Mustern „lernt“, werden ins Continuous Learning v2-System extrahiert, als Instincts mit Confidence-Scores gespeichert und später wiederverwendet.

Session-Aliasse, gelernte Skills und Metriken leben unter einem gemeinsamen Agent-Data-Root (Standard ~/.claude, pro Harness konfigurierbar, falls du ECC in Claude Code und Cursor nutzt).

So greifen die Teile ineinander

Eine typische Session sieht so aus:

1. Session-Start: Ein Hook lädt Kontext aus der letzten Session sowie relevante Skills und Regeln fürs aktuelle Projekt.
2. Du bittest um etwas: Zum Beispiel: „OAuth-Login hinzufügen.“
3. Der Planner-Agent läuft zuerst: Er schreibt einen Blueprint, noch ohne Code.
4. Der TDD-Skill greift: Claude Code folgt dem Workflow mit failing Test, Minimalimplementierung und Refactor.
5. MCP-Tools werden aufgerufen: Vielleicht holt der GitHub-MCP verwandte PRs, oder der Supabase-MCP prüft das Schema.
6. Am Ende läuft der Code-Reviewer-Agent: Er prüft den Diff in einem eigenen Kontextfenster und berichtet zurück.
7. Session-Ende: Ein Stop-Hook schreibt eine Zusammenfassung, extrahiert neue Muster als Instincts und speichert sie fürs nächste Mal.

Das Modell bleibt Claude Code. ECC orchestriert nur, welcher Skill, welcher Agent und welches Tool in welchem Schritt greift.

Skills in Everything Claude Code

Skills sind der Hauptkanal, über den ECC Claude Code steuert.

Ein Skill ist ein Ordner mit einer SKILL.md. Das Markdown definiert Beschreibung, Schritte, Constraints, erwartete Ausgabe und Einsatzkontexte. Es ist schlicht eine Textdatei, die das Modell zur Laufzeit liest.

Und das ist Absicht. ECC „trainiert“ nichts neu, sondern lädt Anweisungen, die Claude im Moment liest und befolgt.

Skills liegen im Verzeichnis skills/ im Repo-Root. Nach der Installation werden sie nach ~/.claude/skills/ kopiert. Claude Code lädt sie als direkte Kinder dieses Ordners.

Jeder Skill-Ordner hat denselben Grundaufbau:

• SKILL.md – die Workflow-Definition
• Optionale Begleitdateien (Templates, Skripte, Beispiele)
• Eine optionale metadata.yaml für Tags und Auffindbarkeit

Skills beeinflussen das Agentenverhalten auf zwei Arten. Erstens liest Claude Code sie zu Sitzungsbeginn und hält sie zur Referenz bereit. Zweitens wählt das Modell je nach Anfrage den passenden Skill. Sagst du „schreibe zuerst einen failing Test“, aktiviert sich der TDD-Skill. Sagst du „prüf das auf SQL-Injection“, aktiviert sich der Security-Review-Skill.

ECC bringt rund 260 Skills mit. Ein paar Beispiele für die Bandbreite:

• frontend-patterns: React- und Next.js-Konventionen. Komponentenstruktur, Hook-Nutzung, Server- vs. Client-Komponenten, State-Management-Patterns.

• django-patterns, django-tdd, django-security, django-verification: Ein kompletter Django-Stack auf vier Skills verteilt – Architektur, Testzyklus, OWASP-ähnliche Audits, Verify-before-Shipping-Schleife.

• architect (gekoppelt mit dem architect Agent): System-Design-Reviews. Der Skill definiert, was eine Architekturprüfung abdeckt, welche Artefakte entstehen und welche Trade-offs offenzulegen sind.

• tdd-workflow: Der Red-Green-Refactor-Zyklus. Failing Test schreiben, minimalen Code zum Bestehen schreiben, refactoren, Coverage prüfen. Der Skill erzwingt die Reihenfolge.

• security-review: OWASP-Top-10-Checkliste, Erkennung hartkodierter Secrets, Input-Validierung und Dependency-Vulnerabilities. Der Skill legt fest, was zu scannen und zu flaggen ist.

Agents in Everything Claude Code

Agents sind spezialisierte Personas mit eigenem Kontextfenster.

Jeder liegt als Markdown-Datei im Ordner agents/ mit Name, Beschreibung, Tool-Allowlist und System-Prompt. Der System-Prompt definiert den Job des Agenten. Die Allowlist steuert, was er darf (Dateien lesen, Bash ausführen, MCP-Server aufrufen, Code schreiben). Claude Code delegiert automatisch Aufgaben an Agents.

ECC hat 66 Agents, die sich in einige Kategorien gruppieren.

Planungs-Agents laufen, bevor Code geschrieben wird.

Der planner zerlegt ein Feature in einen Implementierungs-Blueprint: zu ändernde Dateien, zu definierende Interfaces, zu schreibende Tests, zu behandelnde Edge Cases. Der architect geht eine Ebene höher: Systemdesign, Datenmodell, Service-Grenzen. Diese Agents lesen nur Code und schreiben Pläne.

Coding-Agents übernehmen die Implementierung.

Der tdd-guide erzwingt Test-First. Sprachspezifische Resolver wie go-build-resolver, pytorch-build-resolver und kotlin-build-resolver beheben Build-Fehler in ihren Ökosystemen. Der refactor-cleaner entfernt ungenutzten Code.

Architektur-Agents prüfen strukturelle Entscheidungen.

Der architect deckt Design ab, der database-reviewer betrachtet Query-Patterns und Schemawahl, und der mle-reviewer auditiert produktive ML-Pipelines (Datenverträge, Eval-Abdeckung, Serving, Monitoring).

QA-Agents verifizieren das Ergebnis.

Der code-reviewer prüft Diffs auf Qualität und Sicherheit mit Confidence-Schwelle. Der security-reviewer führt einen OWASP-ähnlichen Durchlauf aus. Der e2e-runner übernimmt Playwright-Ende-zu-Ende-Tests. Sprachprüfer (typescript-reviewer, python-reviewer, go-reviewer, rust-reviewer u. a.) prüfen sprachspezifisch.

Der Grund für die Aufteilung ist Kontextisolation.

Wenn der code-reviewer läuft, bekommt er ein frisches Kontextfenster nur mit dem Diff und dem Review-Skill. Er sieht weder Planungsnotizen noch Verlauf. Er reviewed – Punkt. Diese Fokussierung liefert bessere Ergebnisse, als einen allgemeinen Agenten alles in einem Kontext planen, coden, testen und reviewen zu lassen – was viele Ad-hoc-Setups mit Claude Code am Ende tun.

Kontext- und Speichermanagement in ECC

ECC vergisst zwischen Sessions nicht alles wie Claude Code.

Memory in ECC ist ein System aus Hooks, die zu den richtigen Zeitpunkten Dateien schreiben und wieder laden. Das sind einfache Markdown- und JSON-Dateien auf der Platte.

Drei Dinge bleiben bestehen:

1. Sitzungszusammenfassungen beim Beenden: Ein Stop-Hook läuft nach der letzten Nachricht, nimmt das gesamte Transkript und schreibt eine Zusammenfassung nach ~/.claude/sessions/. Sie deckt ab, woran gearbeitet wurde, was entschieden ist, was offen bleibt. Die nächste Session liest sie per SessionStart-Hook, damit Claude den Anschluss findet.
2. Instincts als extrahierte Muster: Das Continuous-Learning-v2-System beobachtet, was du tust und was funktioniert, und schreibt einzelne Instincts mit Confidence-Score, Aktion, Evidenz und Beispielen. Mit /instinct-status siehst du, was gelernt wurde. Mit /evolve clusterst du verwandte Instincts zu einem neuen Skill.
3. Logfiles für die Betriebsebene: Also Hook-Ausführungen, Skill-Runs, MCP-Calls, Kosten, Fehler. Sie liegen unter ~/.claude/metrics/ und ~/.claude/session-data/ – nützlich fürs Debugging und das Dashboard-GUI im Repo.

Falls das unterschätzt wirkt, hier ein paar Gründe, warum es wichtig ist:

• Langlaufende Projekte: Ein sechsmonatiger Refactor startet nicht jeden Montag neu. Entscheidungen, Trade-offs und bekannte Issues der letzten Woche stehen in der Zusammenfassung, die beim Start lädt.
• Keine Wiederholungsschleifen: Du fügst nicht jedes Mal wieder deinen Stack, eure Konventionen oder „denk dran, wir nutzen Postgres, nicht Oracle“ ein.
• Umgang mit Kontextfenster-Limits: Selbst mit Millionen-Token-Fenstern passt keine sechsmonatige Historie hinein. Zusammenfassungen komprimieren das Wesentliche. Die volle Historie bleibt auf der Platte, das Modell bekommt den relevanten Teil.

Du kannst den geladenen Kontext über Umgebungsvariablen steuern. ECC_SESSION_START_MAX_CHARS begrenzt die geladene Zusammenfassung zu Beginn (Standard 8.000 Zeichen). ECC_SESSION_START_CONTEXT=off schaltet sie für Low-Context-Setups ab. ECC_SESSION_RETENTION_DAYS steuert die Aufbewahrungsdauer vor dem Pruning.

Wenn du ECC auf demselben Rechner in Claude Code und Cursor betreibst, setze ECC_AGENT_DATA_HOME, um die Memories zu trennen. Sonst überschreiben sie sich gegenseitig.

MCP-Support in Everything Claude Code

MCP ist der Weg, wie Claude Code alles aufruft, was nicht Datei oder Shell-Kommando ist.

Das Model Context Protocol ist Anthropics Standard, um Sprachmodelle mit externen Tools zu verbinden. Ein MCP-Server läuft als separater Prozess und bietet typisierte Operationen an: „diese Notion-Seite lesen“ oder „einen PR auf GitHub öffnen“. Claude Code ruft diese Operationen wie Funktionsaufrufe auf.

ECC liefert MCP-Konfigurationen in mcp-configs/mcp-servers.json für gängige Services: GitHub, Supabase, Vercel, Railway, Linear u. a. Jeder Eintrag enthält den Startbefehl, benötigte Environment-Variablen und die Sicherheitsregeln von ECC.

Wichtig: ECC aktiviert das nicht automatisch.

Die MCP-Connector-Policy vom Juni 2026 reduziert die standardmäßig aktivierten Server auf einen (chrome-devtools). Alles andere ist Opt-in. Du kopierst den Eintrag in die .mcp.json deines Projekts oder aktivierst ihn über den /mcp Befehl von Claude Code. Gründe sind teils praktisch (lange MCP-Tolnamen zerschießen manche Gateways) und teils sicherheitsgetrieben (jeder MCP-Server ist eine potenzielle Angriffsfläche).

So sieht der Support in der Praxis aus:

• Externe Integrationen: GitHub-Eintrag in .mcp.json kopieren, Token setzen – und Claude Code kann Issues lesen, PRs öffnen, CI-Status prüfen, ganz ohne Copy-Paste.
• Tool-Calls: Skills und Agents referenzieren MCP-Tools per Name. Ein Deployment-Skill ruft z. B. den Vercel-MCP, ein Datenbank-Review-Agent den Supabase-MCP.
• Projektautomatisierung: Du kannst MCP-Server mit Hooks kombinieren und so Automation über Sessions hinweg bekommen. Ein PR-opened-Hook kann einen Review-Agent starten, der den GitHub-MCP nutzt, um den Diff zu holen, und den Linear-MCP, um das Ticket zu aktualisieren.

Wenn du eigene Instanzen von MCPs betreibst, die ECC mitliefert, setze ECC_DISABLED_MCPS auf eine kommagetrennte Liste. ECC überspringt sie bei Installation und Sync – so verhinderst du doppelte Server mit gleichen Namen.

AgentShield und Sicherheitsfunktionen

Sicherheit ist der Bereich, in dem sich ECC am deutlichsten absetzt.

AgentShield ist ein eigenständiger Security-Auditor, der mit ECC gebündelt kommt. Er scannt Claude-Code-Konfigurationen auf Schwachstellen, Fehlkonfigurationen, Fehler und Injection-Risiken. Er läuft als separates npm-Package (ecc-agentshield), ist aber über den Skill /security-scan in ECC integriert, sodass du ihn aus einer Claude-Code-Session heraus starten kannst.

Der Scan deckt fünf Kategorien ab:

• Secrets-Erkennung: 14 Muster für hartkodierte Zugangsdaten, API Keys, Tokens.
• Berechtigungs-Audit: Welche Tools und Pfade jeder Agent und Skill erreichen kann und ob diese Grants zu weit gefasst sind.
• Hook-Injection-Analyse: Ob Hooks ausnutzbar sind, um beliebige Kommandos auszuführen.
• MCP-Server-Risikoprofil: Was jeder verbundene MCP-Server lesen, schreiben oder aufrufen darf – und wo dadurch Exposure entsteht.
• Agenten-Config-Review: Prompt-Injection-Vektoren, zu breite Tool-Allowlists, fehlende Constraints.

Du kannst ihn ohne Installation so starten:

npx ecc-agentshield scan

Die Ausgabe ist eine Buchstabennote (A bis F) plus eine nach Schwere sortierte Findings-Liste. Kritische Findings beenden mit Code 2.

Ein paar nützliche Flags:

• -fix wendet Auto-Fixes für unkritische Probleme an (exponierte Secrets entfernen, zu weite Berechtigungen reduzieren …)
• -opus führt den Scan durch drei Claude Opus 4.X Agents in einer Red-Team-/Blue-Team-/Auditor-Pipeline aus. Der Angreifer sucht Exploit-Ketten, der Verteidiger bewertet Schutzmechanismen, der Auditor priorisiert die Risiken.
• -stream streamt die Analyse live – hilfreich bei langsamen Configs.

Der Opus-Pipeline-Ansatz unterscheidet AgentShield von einem generischen Linter. Adversarielle Agents versuchen, eigentlich unkritische Komponenten zu Angriffsketten zu verknüpfen – genau dort entstehen viele reale Agent-Angriffe.

Laut Repo bringt AgentShield 102 Static-Analysis-Regeln und 1.282 interne Tests mit 98% Abdeckung. Die Zahlen solltest du mit dem neuesten Release abgleichen – klar ist: Das ist kein 50-Zeilen-Skript.

Ausgabeformate: Terminal (farbcodiert), JSON (für CI), Markdown und HTML. Es gibt außerdem eine GitHub Action und eine separate ECC Tools GitHub App, die AgentShield auf PRs ausführt.

Für die meisten Teams, die Claude Code in Produktion nutzen, ist AgentShield der handfesteste Grund, ECC zu installieren – selbst wenn du den Rest des Frameworks nicht nutzt.

Everything Claude Code installieren

Für ECC gibt es zwei Installationspfade.

Das häufigste Problem ist, die Plugin-Installation über eine manuelle Installation zu stülpen. Beide kopieren dieselben Dateien an dieselben Orte – du hast danach Duplikate. Also vorweg: Entscheide dich für genau einen Pfad.

Vor der Installation stelle sicher, dass Claude Code in Version v2.1.0 oder neuer läuft:

claude --version

Claude-Version

Installation über den Plugin-Manager

Das ist der empfohlene Weg für die meisten Nutzer.

Starte in Claude Code:

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

Plugin-Installation

Der erste Befehl registriert das ECC-Repo als Marketplace. Der zweite installiert das Plugin.

Ein Hinweis: Das Plugin-System verteilt keine Regeln. Regeln sind die immer-gültigen Leitlinien (Coding Style, Git-Workflow, Teststandards, sprachspezifische Patterns) und sind nicht Teil der Plugin-Spezifikation von Claude Code. Du kopierst sie nach der Plugin-Installation manuell.

git clone https://github.com/affaan-m/ECC.git
cd ECC
mkdir -p ~/.claude/rules/ecc
cp -r rules/common ~/.claude/rules/ecc/
cp -r rules/python ~/.claude/rules/ecc/

Kopiere rules/common plus genau ein Sprachpaket, das du nutzt. Im Beispiel oben habe ich Python-Regeln kopiert. Kopiere nicht alles – mehr Regeln bedeuten mehr Kontext in jeder Session, der meiste davon passt nicht zu deinem Projekt.

Installation über Konfigurationsdateien

Nutze diesen Ansatz, wenn du volle Kontrolle willst oder wenn die Plugin-Installation in deinem Setup nicht funktioniert.

git clone https://github.com/affaan-m/ECC.git
cd ECC
npm install
./install.sh --profile full

Unter Windows:

.\install.ps1 --profile full
# oder
npx ecc-install --profile full

Das kopiert Agents, Skills, Commands, Hooks und Regeln in dein ~/.claude/ Verzeichnis. Keine Plugin-Schicht – alles lebt als Dateien auf der Platte, die Claude Code zu Sitzungsbeginn liest.

Ein paar Profiloptionen, die du kennen solltest:

• -profile minimal: Nur Regeln, Agents, Commands und Kern-Skills – ohne Hooks.

• -profile core: Der Standard – Hooks inklusive.

• -profile full: Alles aus dem Repo.

Du kannst mit --modules oder --with auch gezielt Komponenten installieren:

./install.sh --target claude --modules hooks-runtime
npx ecc install --profile minimal --target claude --with capability:machine-learning

Wenn du unsicher bist, welche Komponenten für dich passen, frag den mitgelieferten Advisor:

npx ecc consult "security reviews" --target claude

Er gibt passende Komponenten und die genauen Installationsbefehle zurück.

Installation verifizieren

Prüfe, was installiert wurde:

/plugin list ecc@ecc

Plugin-Installationsprüfung

Das zeigt Agents, Commands und Skills aus dem Plugin. Für manuelle Installationen nutze den Lifecycle-Wrapper:

node scripts/ecc.js list-installed
node scripts/ecc.js doctor

doctor prüft fehlende Dateien, defekte Hooks und Versionsmismatches. Wenn etwas rot ist, führe aus:

node scripts/ecc.js repair

Um zu bestätigen, dass Claude Code das neue Plugin sieht, öffne eine Session und teste einen Slash-Befehl:

/ecc:plan "Add user authentication"

ECC-Plan-Ausgabe

Bei Plugin-Install ist der Namensraum-Präfix /ecc: Pflicht. Bei manueller Installation reicht die Kurzform (/plan).

Wenn etwas doppelt wirkt oder kaputt ist, installiere nicht darüber. Starte node scripts/uninstall.js --dry-run, um zu sehen, was entfernt würde, dann node scripts/uninstall.js zum Aufräumen. ECC entfernt nur Dateien, die es installiert hat – andere Configs bleiben unverändert.

Mit Skills, Commands und Workflows arbeiten

Das meiste in ECC läuft über Skills statt über Commands.

Grund: Der Ordner commands/ wird aus Kompatibilitätsgründen weiter gepflegt, aber neue Workflow-Entwicklung passiert zuerst in skills/.

Diese Nutzungsmuster decken den Großteil deiner täglichen Arbeit ab:

Skills werden meist implizit aufgerufen

Du rufst selten einen Skill beim Namen. Du beschreibst, was du willst – Claude Code wählt den passenden Skill. Sagst du „schreibe zuerst einen failing Test“, aktiviert sich tdd-workflow. In der Antwort siehst du, welche Skills geladen wurden.

Wenn du explizit sein willst, referenziere den Skill im Prompt: „Nutze den Skill django-tdd für den neuen Endpoint.“ Oder führe einen umhüllenden Befehl aus:

/code-review
/security-scan

/ecc:plan "Add OAuth login"

Der Präfix /ecc: ist bei Plugin-Install erforderlich. Bei manueller Installation gilt die Kurzform (/plan, /code-review).

ECC-Planungsphase-Ausgabe

Datei-Scoping ist Teil des Workflows

Die meisten Agents und Skills arbeiten auf einem Scope: Datei, Verzeichnis, Diff, PR. Du setzt den Scope, indem du die Datei im Prompt erwähnst, sie im Editor öffnest oder den Agent auf einen Pfad zeigst:

/code-review src/auth/
/python-review services/billing/payment.py

Der Agent übernimmt den Scope, lädt nur benötigte Dateien und läuft im eigenen Kontextfenster.

Shell-Integration läuft über das Bash-Tool von Claude Code

Skills können für echte Ausführung in die Shell springen: Tests laufen lassen, builden, linten oder eine CLI aufrufen. Der TDD-Skill startet pytest oder go test. Der Build-Fix-Agent führt den echten Build aus, um reale Fehler zu sehen. Der Security-Scan-Skill startet npx ecc-agentshield scan und parst die Ausgabe.

Der Skill definiert, welche Shell-Kommandos wann laufen. Hooks können ebenfalls bei Tool-Events Shell-Kommandos ausführen (z. B. Typecheck nach jedem Edit, vor dem Speichern vor console.log warnen).

MCP-Management ist überwiegend Opt-in

Nach der Installation aktiviert ECC standardmäßig genau einen MCP-Server (chrome-devtools). Um weitere hinzuzufügen, kopierst du Einträge aus mcp-configs/mcp-servers.json in die .mcp.json deines Projekts und aktivierst sie über den Befehl /mcp in Claude Code. Die /mcp Oberfläche unterstützt Aktivieren, Deaktivieren und Re-Auth.

Wenn du eigene Kopien von MCP-Servern betreibst, die ECC mitliefert, setze:

export ECC_DISABLED_MCPS="github,supabase"

Installer und Sync von ECC überspringen sie, damit nicht zwei gleiche Server um dieselben Tool-Namen konkurrieren.

Workflows greifen ineinander

Du führst Skills nicht einzeln nacheinander aus. Ein typischer Feature-Workflow sieht so aus:

/ecc:plan "Add OAuth login with Google"
# planner agent schreibt einen Blueprint

# tdd-workflow Skill aktiviert sich bei der Implementierung
# Tests schlagen fehl, Code wird geschrieben, Tests bestehen

/code-review
# code-reviewer Agent auditiert den Diff

/security-scan
# AgentShield prüft neuen Code und Config

Jeder Schritt nutzt einen anderen Agenten in einem frischen Kontextfenster. Die Hauptsession koordiniert, die Sitzungszusammenfassung hält die Kette fest und stellt sie der nächsten Session bereit.

Everything Claude Code vs. konkurrierende Konfigurations-Frameworks

ECC ist nicht das einzige Konfigurations-Layer für Claude Code. Einige Alternativen verfolgen ähnliche Ziele mit anderen Trade-offs.

Wichtig ist die Kategorisierung. ECC konkurriert mit anderen Konfigurations-Frameworks, die auf Claude Code aufsetzen. Es konkurriert nicht mit den Harnesses, neben denen es läuft (Cursor, Codex, OpenCode, Zed) oder mit eigenständigen Agentenplattformen (OpenHands, LangGraph, CrewAI) – das sind andere Tool-Kategorien.

Drei Rivalen tauchen am häufigsten auf.

BMAD-Method ist ein agiles SDLC-Framework mit rollenbasierten Spezial-Agents (Analyst, PM, Architect, Scrum Master, Developer, QA). Es läuft über Claude Code, Cursor und Windsurf via npx bmad-method install. Es glänzt in der frühen Planung, indem es vage Ideen vor dem Coden in PRD, Architektur-Dokument und zerlegte Stories überführt. Die Ausführungs-Tools sind leichter als bei ECC. Es gibt keinen Security-Scanner und keinen MCP-Katalog. Weniger sprachspezifische Patterns.

SuperClaude ist ein leichtgewichtiges, Markdown-basiertes Config-Framework. Rund 30 Slash-Commands, 20 Agents und ein paar Verhaltensmodi. Installation per pip install SuperClaude. Es ist bewusst simpler als ECC – ohne Security-Scanning und ohne Orchestrierungs-Runtime. Es gibt auch keine Memory-Schicht jenseits dessen, was Claude Code bietet. Wenn du ein funktionierendes CLAUDE.md plus gut getestete Prompts willst, ist SuperClaude eine gute Wahl.

claude-flow / Ruflo (früher Claude Flow, umbenannt Anfang 2026) ist ein Multi-Agent-Schwarm-Orchestrator. Er nutzt die SPARC-Methodik (Specification, Pseudocode, Architecture, Refinement, Completion) und betreibt queen-geführte Hierarchien aus 60–100+ spezialisierten Agents parallel. Er hat persistentes Memory via AgentDB und arbeitet mit Claude, GPT, Gemini und Ollama. Die Infrastruktur ist schwerer als bei ECC und auf parallele Agentenarbeit statt auf Single-Session-Produktivität ausgelegt.

Wenn du mehr Optionen sichten willst, bevor du dich festlegst: awesome-claude-code ist ein kuratiertes Verzeichnis für Claude-Code-Ressourcen (Agents, Skills, Plugins, MCP-Server, Configs). Dort findet ein Großteil der Community-Entdeckung statt.

Kurz gesagt: Nimm BMAD für agile Planung, SuperClaude für eine leichte Config-Schicht, Ruflo für parallele Multi-Agent-Arbeit – und ECC, wenn du eine vollständige Engineering-Plattform mit Sicherheitstools und persistenter Memory willst.

Für wen eignet sich Everything Claude Code?

ECC ist nicht für alle. Wenn du Claude Code nur ein paar Mal pro Woche für Kleinkram nutzt, wirkt das Framework wie Overhead mit wenig Gegenwert. Ein einzelnes CLAUDE.md mit 100 Zeilen deckt das meiste ab, was du brauchst.

ECC zahlt sich aus, wenn du darüber hinaus bist.

Diese Szenarien sind ein besserer Fit als Vanilla Claude Code:

• KI-Ingenieurinnen und -Ingenieure, die agentische Systeme bauen: Wenn du Agenten-Workflows designst oder ausrollst, ist ECC eine Referenz in Funktion. Lies die Agent-Prompts, Skill-Definitionen, Hook-Configs – und übernimm, was passt.
• Produktivitätsfans unter Entwicklerinnen und Entwicklern: Wer Zeit in Tooling, Dotfiles, Editor-Setup und Shell steckt, findet in ECC dieselbe Art Investment für Claude Code. Je mehr du es nutzt, desto mehr lohnt es sich.
• Teams, die Claude Code täglich als Infrastruktur nutzen: Wenn euer Team täglich Features shipped, reviewed, plant oder refactort, summiert sich die Zeitersparnis durch Konsistenz und Onboarding. Neue Teammitglieder bekommen dieselben Agents und Workflows.
• Alle, die komplexe Agent-Workflows bauen: Mehrstufige Pipelines, Sub-Agent-Orchestrierung, MCP-Chaining, persistenter Kontext – nur ein paar Beispiele. ECC hat vieles davon bereits gelöst, und die Patterns sind wiederverwendbar, selbst ohne Komplettinstallation.

Und hier, wer eher nicht zu ECC greifen sollte:

• Gelegenheitsnutzer von Claude Code: Ein paar Sessions pro Woche à la „hilf mir, dieses Skript zu debuggen“ brauchen keine 60+ Agents, 260+ Skills und Memory-Layer. Der Setup-Overhead lohnt nicht.
• Einfache, einmalige Aufgaben: Kleine Skripte, Fixes, Demos, Wegwerf-Prototypen. Vanilla Claude Code ist dafür gut – ECC würde nur Reibung hinzufügen.
• Teams mit funktionierendem Setup: Wenn euer CLAUDE.md sitzt und die Abläufe stabil sind, kostet der Umstieg Zeit. Nimm, was dir gefällt, und lass den Rest.

Wenn du unsicher bist, lies das Repo, kopiere zwei, drei interessante Agents und Skills – und lass die Komplettinstallation erst mal sein.

Stärken und Grenzen von ECC

Zum Schluss ein Blick auf Stärken und Schwächen von ECC – beides wichtig für deine Entscheidung.

Vorteile

• Große Skill-Bibliothek: Rund 260 Skills zu TDD, Security-Audits, Framework-Patterns, Sprachidiomen, ML-Engineering, Deployment und mehr. Auch ohne Installation taugt das Repo als Referenz zum Schreiben guter Skill-Definitionen.
• Workflow-Wiederverwendung: Du bekommst getestete Prompts für Review, Planung, Refactoring und Tests. Der Code-Reviewer-Agent wird oft zitiert – auch von Leuten, die ECC nicht nutzen, aber den Prompt übernommen haben.
• Persistentes Memory: Sitzungszusammenfassungen und kontextübergreifender Speicher funktionieren out of the box. Die meisten anderen Konfigurationen ignorieren Memory völlig.
• Starker MCP-Support: Vorgefertigte Konfigs für GitHub, Supabase, Vercel, Railway u. a.
• AgentShield: Der Security-Scanner allein ist ein Installationsgrund – auch wenn du sonst nichts nutzt. Vergleichbares bringen nur wenige Configs mit.
• Open Source unter MIT: Kein Paywall im Kern. Die gehostete GitHub App und ECC Pro sind separat.
• Cross-Plattform: Funktioniert mit Claude Code, Cursor, Codex, OpenCode, Zed, Gemini u. a. Wechselst du oder nutzt mehrere, bleiben Agents und Skills gleich.

Einschränkungen

• Lernkurve: 60+ Agents, 260+ Skills, drei Installationspfade, vier Profiltypen und ein Stapel Env-Variablen. Die erste Woche verbringst du damit, zu verstehen, was geladen ist und was was tut.
• Setup-Komplexität: Plugin vs. manuell, das „Regeln-nicht-per-Plugin“-Thema, doppelte Hooks in älteren Claude-Code-Versionen, MCP Enable/Disable, Agent-Data-Home bei Multi-Harness. Dokumentiert, aber dennoch Aufwand.
• Wartungsaufwand: Das Repo aktualisiert sich regelmäßig. Katalogzahlen ändern sich, Skill-Namen auch.
• Abhängigkeit vom Claude-Code-Ökosystem: ECC hängt an Plugin-Spez, Hook-System und MCP-Support. Wenn Claude Code das ändert, muss ECC nachziehen.
• Over-Engineering für viele Fälle: Für die meisten Teams deckt ein gutes CLAUDE.md mit 60–200 Zeilen 80% von ECC ab. Die restlichen 20% sind wertvoll – aber nur, wenn du sie nutzt.

Das Framework ist derzeit die vollständigste Konfigurationsschicht für Claude Code. „Am vollständigsten“ heißt jedoch nicht „für alle nötig“.

Fazit

Wenn du Claude Code täglich nutzt, lohnt sich der Blick auf ECC. Wenn nicht, ist das Repo trotzdem lesenswert – als funktionierende Referenz dafür, wie man Agent-Workflows baut, die in der Praxis halten.

So oder so: ECC zeigt deutlich, dass sich Softwareentwicklung in Richtung programmierbarer Agenten-Pipelines bewegt – weg von Einzelnachrichten-Chats. Die Frameworks dafür sind noch jung, und ECC ist einer der vollständigsten Versuche bisher. Es wird nicht der letzte sein – und genau das ist der Punkt.

Wenn du neu in generativer KI und agentischem Coding bist, melde dich zu unserem Kurs Generative AI Concepts an. Er legt ein starkes Fundament für die Zukunft.