direkt zum inhalt

7. Oktober 2026kiunternehmen

ECC für Claude Code: 68 KI-Agenten sinnvoll einsetzenECC for Claude Code: using AI agents with purpose

ECC bündelt Agenten, Skills, Regeln und Prüfungen für Claude Code. Ich zeige, was davon im Alltag zählt, wie die Installation sauber gelingt und wo Teams klare Grenzen ziehen sollten.ECC brings together agents, skills and checks for Claude Code. This guide shows how to start with verified sources, suitable rules and a reliable development flow.

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.

Vier leuchtende Symbole für Planung, Umsetzung, Prüfung und Sicherheit, verbunden durch eine orange Lichtlinie
Titelbild KI-generiert, als solches gekennzeichnet.

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.

An AI agent can generate code. A reliable development flow needs more: an order of work, checks and clear ownership. That is where ECC comes in. The open-source project brings together agents, skills, rules and security checks for Claude Code and other coding environments.

Four glowing symbols for planning, implementation, review and security, connected by an orange light line
AI-generated title image, labelled as such.

what ECC does at its core

ECC is not one command that automatically improves a project. It is a toolkit for recurring development work: structure requirements, make changes, run tests, get a fresh review perspective and retain useful outcomes. The project lists 68 agents, 292 skills and 94 compatibility commands for the current plugin version. Those numbers describe scope, not the right starting point.

For a team, a simpler question matters: where does work get lost today? In unclear requirements, missing tests, shallow reviews or security checks that happen only shortly before release? Add an extension only after the bottleneck is clear.

four sentences for daily work

In daily work, the scope can be reduced to four understandable steps: plan, build, secure and test. Planning records the goal, impact and acceptance check before the first edit. While building, the change stays small and verifiable. Security means challenging changes and configuration deliberately. Tests provide evidence that the intended case works and that a deliberately broken case does not pass unnoticed.

That is not a new method. The benefit is that the flow becomes tangible in the work environment. An agent can assist with a clearly bounded task. It does not replace the decision about scope or responsibility for a release.

copyable prompt templates

A useful request to a coding agent does not start with “make this better”. It names the result, the boundaries and the proof. That lets the agent decide which available capabilities actually fit. The templates below are deliberately concise. Replace the square brackets and remove anything that does not apply to your task.

1. plan first, change nothing yet

Plan this change: [goal in one sentence].

Inspect the existing flow first and name the affected files.
Define no more than five work steps, each with one acceptance check.
Name risks, open assumptions and a rollback path.
Do not write code or change files yet.

This prompt prevents the most common false start: the agent jumps straight to a solution before it is clear what the change touches. For login, payments, data migrations or integrations in particular, the plan should come before the first line of code.

2. implement a confirmed plan

Implement the confirmed plan for [goal].

Work only in these files or modules: [scope].
Keep the change small and match the existing style.
Write or extend tests for the intended behaviour.
Then run [verification command] and name changed files,
test result and remaining risks. No commit, no deploy.

The scope sentence protects against well-intentioned overreach. An agent will often see room to improve things outside the request. That may be valid, but it is a separate decision. With a clear boundary, it remains traceable which change belongs to which result.

3. security review without automatic changes

Review [file, diff or area] for real security risks.

Consider inputs, permissions, secrets, external URLs,
redirects and data access. List only findings with file, line,
impact and a bounded fix. No style notes.
Change nothing and run no production-facing actions.

“Real risks” matters. A long list of theoretical notes helps nobody. A useful finding points to the concrete location, explains the harm and can be checked with a small change. For highly critical areas, an independent second review remains worthwhile.

4. acceptance with a counter-check

Verify the implementation of [goal] against these criteria:
[criterion 1]
[criterion 2]
[criterion 3]

Run the fitting tests and a counter-check: briefly change a relevant
test case so it must fail, undo the change and verify again. Report only
evidenced results and open points.

The counter-check answers an uncomfortable but central question: does the green test actually check the right thing? If a deliberately broken case remains green, the proof has no value. This loop takes little longer than a plain test run and prevents a great deal of false certainty.

5. a handover prompt for the team

Create a handover for [recipient or next team].

It must include: goal, actual scope, changed files,
checks run with their outcome, unchecked items, known risks
and the concrete next step. Do not present assumptions as facts.

That turns an agent's result into a useful basis for work. In longer efforts, the handover matters more than a long chat history: it separates confirmed facts from open points and makes the next step possible without guesswork.

installing cleanly

The official documentation offers two paths for Claude Code. Either add the plugin directly in the Claude Code chat:

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

Or start the guided setup in a terminal:

npx [email protected] setup

Both paths install the same extension. Choose one; do not layer them. If you still use the earlier name everything-claude-code, read the migration notes first. The current plugin ID is ecc@ecc.

Rule packs are separate. Claude Code plugins cannot distribute them automatically. Start with the common rules and exactly one language or stack. A complete rules folder for every possible technology makes the environment heavier, not better.

where the boundary sits

Many agents do not mean that every task should be delegated. A small change often needs only a clear test and a review. A larger feature benefits from planning, implementation and an independent counter-check. The right number is the one that covers a concrete risk without creating a second opaque process layer.

Hooks, MCP servers and project instructions deserve particular care. They can run commands, hold access or shape how an agent works. Treat them like code: verify the source, keep permissions narrow, test the effect and retain a way back.

my starting point

I would not start ECC with a large agent catalogue. A test project with one recurring flow is more useful: plan a small task, implement it with a clear check, review it afterwards and document the result. Add further rules or specialised agents only once this loop is stable.

That keeps the benefit visible. The system helps where it reduces friction instead of becoming another task beside the product work itself.

the core in three sentences

ECC brings together tools for a traceable AI-supported development flow. The right entry point is not the highest possible number of agents, but a named gap in your own process. Installations and configuration deserve the same security review as the code they influence.

frequently asked questions

What is ECC for Claude Code?

ECC is an open-source plugin for AI-supported coding environments. It brings together specialised agents, skills, rules and verification flows so planning, implementation, review and verification work together more clearly.

How do I install ECC in Claude Code?

The official route is either the ecc@ecc plugin or the guided ecc-universal package. Both install the same extension. Choose one route and do not layer a manual installation on top.

Does every project need all ECC agents?

No. Value does not come from as many agents as possible. A small team should start with one clear flow and a few fitting rules, then add extensions only when a recurring gap becomes visible.

What matters most during installation?

Install only from sources named by the project as official. Hooks, MCP servers and project instructions are executable configuration and deserve the same review as other code.

sources and status

As of 7 October 2026. Source: ECC on GitHub, README, plugin metadata and migration notes, read on 7 October 2026. ECC is actively developed; versions, scope and installation steps can change.

geschrieben vonwritten by · business transformation, ki und führung im mittelstand. methode: core+.business transformation, ai and leadership for mid-sized companies. method: core+.

weiterlesenkeep reading

← zurück zum herrlichblog← back to the herrlichblog