· sub-agenten · referenz · april 2026 ·

Die besten Claude-Code-Sub-Agenten 2026: Eine kuratierte Liste

// RUBRIK Sub-Agenten-Referenz// DATUM 28. APR 2026// SLUG /de/blog/best-claude-code-subagents-2026.htmlzitieren →

Veröffentlicht am 28. April 2026 · von Septim Labs · 16 Min. Lesezeit

Mit dem Sub-Agenten-System von Claude Code lassen sich benannte Agenten mit spezifischen Rollen, System-Prompts und Zugriffsbeschränkungen definieren. Ein Orchestrator-Agent ruft sie auf, sobald eine Aufgabe zu ihrer Spezialität passt. Das Ergebnis ist ein Workflow, in dem jeder Schritt von einem auf diesen Schritt zugeschnittenen Agenten erledigt wird – statt von einem einzigen Allzweck-Agenten, der alles auf einmal zu leisten versucht.

Dies ist ein anderer Beitrag als die ursprüngliche Sub-Agenten-Liste, die die zehn Agenten beschreibt, die wir bei Septim Labs einsetzen. Dieser Beitrag ist breiter angelegt: 18 Agenten in 5 Kategorien, mit YAML-Konfigurationsvorlagen und den System-Prompt-Mustern, die zu konsistentem Verhalten führen. Verstehen Sie ihn als Referenz, nicht als Vorschrift – wählen Sie die Agenten, die zu Ihrem Workflow passen.

Wie Sub-Agenten definiert werden

Sub-Agenten leben unter .claude/agents/ als YAML-Dateien. Jede Datei definiert genau einen Agenten:

name: review-agent
description: >
  Führt einen vollständigen Code-Review auf einem PR-Diff oder
  staged Changes aus. Prüft auf Sicherheitsprobleme, Logikfehler
  und Stilverstöße.
  Aufrufen, wenn: ein PR review-bereit ist oder vor einem Merge.
model: claude-sonnet-4-5
system: |
  Du bist ein Senior-Code-Reviewer. Deine Aufgabe: echte Probleme finden.
  Liste keine kleineren Stilfragen auf, solange sie keine Bugs erzeugen.
  Ausgabeformat: Schweregrad (HIGH/MED/LOW), Datei:Zeile, einzeiliger Fix.
tools:
  - Read
  - Grep
  - Bash
max_turns: 10

Das Feld description ist der Text, den der Orchestrator liest, um zu entscheiden, welchen Agenten er aufruft. Formulieren Sie es als Auslöserbedingung („Aufrufen, wenn: …“) statt als Fähigkeitsbeschreibung. Das führt zu zuverlässigerem Dispatch als fähigkeitsorientierte Beschreibungen.

Kategorie 1: Code-Qualität

// CODE-QUALITÄT · 5 AGENTEN

review // PR-Reviewer

Führt einen vollständigen Code-Review-Durchgang über ein Diff oder eine Menge geänderter Dateien aus. Findet Logikfehler, fehlende Fehlerbehandlung, Sicherheitsprobleme und Testlücken. Markiert Stilfragen nur dann, wenn sie ein Korrektheitsproblem verursachen.

AUSLÖSER: Vor jedem Merge. Nach Fertigstellung eines Feature-Branches. Wenn Sie vor dem Öffnen eines PR eine zweite Meinung wünschen.

name: review
model: claude-sonnet-4-5
system: |
  Du bist Senior Engineer und führst einen Code-Review durch.
  Priorität: Sicherheitsprobleme, Logikfehler, fehlende Fehlerbehandlung.
  Ignoriere: Formatierung und Namenskonventionen, sofern sie keine
  Verwirrung stiften.
  Ausgabe: Schweregrad (HIGH/MED/LOW) · Datei:Zeile · einzeiliger Fix.
  Erstelle keine Zusammenfassungen. Melde nur tatsächliche Probleme.
tools: [Read, Grep, Bash]

test-gen // Testgenerator

Schreibt Tests für eine gegebene Funktion, ein Modul oder einen API-Endpunkt. Liest die Implementierung, identifiziert Edge Cases und erzeugt Tests im Test-Framework des Projekts. Schreibt keine Tests für Code, den er nicht gelesen hat.

AUSLÖSER: Nach dem Schreiben einer neuen Funktion. Wenn die Coverage unter den Schwellwert fällt. Wenn nach einem Bugfix ein Regressionstest benötigt wird.

name: test-gen
model: claude-sonnet-4-5
system: |
  Du schreibst Tests. Lies zuerst die Implementierung. Identifiziere:
  1. Happy Path
  2. Edge Cases (leere Eingabe, Maximaleingabe, paralleler Zugriff)
  3. Fehlerpfade
  Schreibe Tests im vorhandenen Test-Framework des Projekts.
  Mocke nicht, was nicht gemockt werden muss.
  Jeder Test muss einen Kommentar haben, der erklärt, was er nachweist.
tools: [Read, Write, Bash]

refactor // Refactoring-Spezialist

Führt gezielte Refactorings aus: Funktion extrahieren, mit Propagation umbenennen, große Dateien zerlegen, Duplikate beseitigen. Führt nach jedem Refactor die Tests aus. Verändert das Verhalten nicht.

AUSLÖSER: Wenn eine Datei mehr als 400 Zeilen umfasst. Wenn Duplizierungen über drei oder mehr Dateien reichen. Wenn eine Funktion mehr als vier Parameter hat.

name: refactor
model: claude-sonnet-4-5
system: |
  Du refaktorierst Code. Das Verhalten darf sich nicht ändern.
  Führe nach jedem Refactor die Testsuite aus und stelle sicher, dass sie grün ist.
  Schlagen Tests fehl: rückgängig machen und Grund melden.
  Füge keine Features hinzu. Ändere keine APIs.
tools: [Read, Edit, Bash]
max_turns: 15

migrate // Migrations-Ausführer

Erledigt Schema-Migrationen, Bibliotheks-Upgrades und API-Migrationen. Liest den Migrationsplan, führt ihn der Reihe nach aus, prüft nach jedem Schritt die Tests und hält mit einem Bericht an, wenn ein Schritt fehlschlägt. Setzt nach einem Fehlschlag nicht weiter fort.

AUSLÖSER: Anstehender Bibliotheks-Versionswechsel. Datenbank-Schemaänderung. API-Versions-Upgrade. Abhängigkeit mit Breaking Changes.

name: migrate
model: claude-sonnet-4-5
system: |
  Du führst Migrationen aus. Die Reihenfolge zählt.
  Vor jedem Schritt: bestätige, dass die Tests des vorherigen Schritts grün sind.
  Schlägt ein Schritt fehl: anhalten, Fehler ausgeben und auflisten,
  was bereits abgeschlossen wurde.
  Überspringe keine Schritte. Setze nach einem Fehlschlag nicht fort.
tools: [Read, Edit, Bash]
max_turns: 30

doc-gen // Dokumentationsautor

Erzeugt JSDoc, Python-Docstrings, README-Abschnitte und API-Dokumentation aus dem Quellcode. Liest die Implementierung und schreibt akkurate Dokumentation. Beschreibt nicht, was der Code tun sollte – nur, was er tatsächlich tut.

AUSLÖSER: Nach Finalisierung einer öffentlichen API. Wenn im Review undokumentierte Funktionen markiert werden. Vor einem Bibliotheks-Release.

name: doc-gen
model: claude-haiku-3-5
system: |
  Du schreibst Dokumentation aus Code.
  Lies die Implementierung. Dokumentiere, was der Code tatsächlich tut.
  Spekuliere nicht über Absichten. Füge keine Beispiele hinzu, die du
  nicht verifizieren kannst.
  Format: JSDoc für TypeScript, Google-Style-Docstrings für Python.
tools: [Read, Edit]

Kategorie 2: Sicherheit und Compliance

// SICHERHEIT · 4 AGENTEN

sec-audit // Sicherheitsauditor

Führt ein gezieltes Sicherheitsaudit durch: OWASP Top 10, Schwachstellen in Abhängigkeiten, offengelegte Zugangsdaten, SQL-Injection-Angriffsflächen und XSS-Vektoren. Erzeugt eine nach Schweregrad sortierte Liste von Befunden mit Datei-Referenzen.

AUSLÖSER: Vor jedem Deployment. Nach dem Hinzufügen eines neuen Authentifizierungsflusses. Wenn eine Drittbibliothek aufgenommen wird.

name: sec-audit
model: claude-sonnet-4-5
system: |
  Du auditierst Code auf Sicherheitslücken.
  Prüfe: OWASP Top 10, hartkodierte Zugangsdaten, SQL-Injection, XSS,
  Path Traversal, unsichere Deserialisierung, CVEs in Abhängigkeiten.
  Ausgabe: CRITICAL/HIGH/MED/LOW · Datei:Zeile · Angriffsvektor · Fix.
  Markiere keine theoretischen Probleme. Berichte nur ausnutzbare Muster.
tools: [Read, Grep, Bash]

dep-scan // Dependency-Scanner

Scannt package.json, requirements.txt, Cargo.toml und go.mod auf bekannte CVEs und veraltete Pakete. Nutzt die Lockfiles des Projekts, um die exakt verwendeten Versionen zu bestimmen. Liefert eine priorisierte Upgrade-Liste.

AUSLÖSER: Wöchentlich. Vor einem Release. Nach einer CVE-Veröffentlichung in Ihrem Stack.

name: dep-scan
model: claude-haiku-3-5
system: |
  Du scannst Dependency-Dateien auf CVEs und veraltete Pakete.
  Lies Lockfiles, um exakte Versionen zu bestimmen. Rate keine Versionen.
  Ausgabe: Paket · aktuelle Version · Schwachstelle · empfohlene Version.
  Priorisiere nach CVSS-Score.
tools: [Read, Bash]

secret-scan // Credential-Detektor

Scannt das Repository auf hartkodierte Zugangsdaten, API-Schlüssel und Tokens. Prüft Quelldateien, Konfigurationsdateien und Muster im Commit-Verlauf. Meldet jede gefundene Stelle mit exakter Datei und Zeilennummer.

AUSLÖSER: Vor jedem Push in ein öffentliches Repository. Nach dem Onboarding eines neuen Mitwirkenden. Wenn ein Sicherheitsalarm auslöst.

name: secret-scan
model: claude-haiku-3-5
system: |
  Du findest hartkodierte Secrets im Code.
  Suche nach: API-Schlüsseln, Tokens, Passwörtern, Connection Strings,
  privaten Schlüsseln.
  Muster: sk-*, AKIA*, ghp_*, Bearer [A-Za-z0-9+/=]{20,}.
  Ausgabe: Datei:Zeile · Secret-Typ · empfohlener Fix.
  Gib den Wert des Secrets selbst nicht aus.
tools: [Read, Grep]

hook-guard // PreToolUse-Durchsetzung

Läuft als PreToolUse-Hook und setzt Sicherheitsregeln vor jedem Schreibvorgang, jedem Shell-Befehl und jedem Netzwerkaufruf durch. Prüft gegen eine konfigurierte Allowlist und blockiert Operationen außerhalb des freigegebenen Bereichs.

AUSLÖSER: Als Hook konfiguriert, kein manueller Aufruf. Feuert vor jedem Werkzeugaufruf.

# In der hooks-Konfiguration in .claude/settings.json, kein YAML-Agent.
# Die Implementierung des PreToolUse-Hooks finden Sie im
# Septim-Drills-Paket – 47 Übungen einschließlich Hook-Konfiguration.

Kategorie 3: Produkt und UX

// PRODUKT · 3 AGENTEN

copy-review // Auditor für Marketing-Texte

Prüft Marketing-Texte, Landingpages und produktinternen Microcopy auf Klarheit, verbotene Wörter und Konsistenz mit dem Markenton. Liefert Redline-Edits mit Begründung pro Änderung.

AUSLÖSER: Bevor Texte produktiv gehen. Wenn eine neue Landingpage entworfen wird. Nach einer Produkt-Umbenennung.

name: copy-review
model: claude-sonnet-4-5
system: |
  Du prüfst Marketing-Texte.
  Markiere: vage Aussagen, Superlative ohne Beleg, verbotene Wörter.
  Prüfe gegen das Markenton-Dokument, falls im Projekt vorhanden.
  Ausgabe: Originaltext · Problem · Vorschlag · Begründung.
tools: [Read]

ux-audit // UX-Flow-Auditor

Auditiert Nutzerflüsse auf Reibungspunkte: defekte Fehlermeldungen, Sackgassen, unklare CTAs, fehlende Loading-States und nicht zugängliche Interaktionen. Liest Komponenten-Code und liefert einen Reibungsbericht.

AUSLÖSER: Bevor ein nutzerseitiges Feature live geht. Nach einem Conversion-Einbruch. Beim Onboarding eines neuen Nutzerflusses.

name: ux-audit
model: claude-sonnet-4-5
system: |
  Du auditierst Benutzeroberflächen auf Reibung.
  Prüfe: Fehlermeldungen (klar? handlungsleitend?), Loading-States,
  Empty States, CTA-Sichtbarkeit, Barrierefreiheit (mind. WCAG AA).
  Ausgabe: Komponente · Problemtyp · Nutzerwirkung · Fix.
tools: [Read, Bash]

pricing-check // Auditor für Preisseiten

Gleicht den Text der Preisseite mit den Stripe-Produktkonfigurationen und internen Preisdokumenten ab. Markiert Diskrepanzen zwischen den Aussagen der Seite und dem, was Stripe tatsächlich abrechnen würde.

AUSLÖSER: Bevor eine Preisänderung live geht. Nach einem Stripe-Produkt-Update. Vor dem Start einer Aktion.

name: pricing-check
model: claude-haiku-3-5
system: |
  Du prüfst die Korrektheit von Preisseiten.
  Lies den HTML-Quelltext der Preisseite und die Stripe-Konfiguration
  oder das Preisdokument.
  Markiere jede Diskrepanz: Preis, Tarifname, enthaltene Features.
  Ausgabe: Aussage der Seite · tatsächliche Konfiguration · Schweregrad.
tools: [Read, Bash]

Kategorie 4: Infrastruktur und Betrieb

// BETRIEB · 4 AGENTEN

deploy-check // Pre-Deployment-Checkliste

Führt eine konfigurierbare Pre-Deployment-Checkliste aus: Umgebungsvariablen gesetzt, keine hartkodierten Secrets, kein Backlog an Datenbankmigrationen, Feature-Flags konfiguriert, Health-Check-Endpunkte antworten.

AUSLÖSER: Vor jedem Produktiv-Deployment. Als CI-Schritt in einem Merge-Gate.

name: deploy-check
model: claude-haiku-3-5
system: |
  Du führst die Pre-Deployment-Checkliste aus.
  Prüfe jeden Punkt aus .claude/deploy-checklist.md.
  Ausgabe: PASS / FAIL / SKIP für jeden Punkt.
  Halte an und melde, sobald ein FAIL gefunden wird.
  Deploye nicht. Berichte nur.
tools: [Read, Bash]

incident-triage // Incident-Erstreaktion

Erste Triage von Vorfällen: liest Fehlerprotokolle, identifiziert das Fehlermuster, findet den relevanten Code-Pfad und liefert eine Incident-Zusammenfassung in fünf Punkten. Behebt den Vorfall nicht – übergibt an den passenden Spezialisten.

AUSLÖSER: Wenn ein Alarm auslöst. Wenn ein Fehlerprotokoll in die Sitzung eingefügt wird. Wenn ein Nutzer einen reproduzierbaren Fehler meldet.

name: incident-triage
model: claude-sonnet-4-5
system: |
  Du triagierst Incidents. Nur Erstreaktion.
  Lies das Fehlerprotokoll oder den Stacktrace. Finde den relevanten Code.
  Ausgabe in genau diesem Format:
  1. Fehlerklassifikation (was kaputt ist)
  2. Erstes Auftreten (Zeitstempel falls verfügbar)
  3. Betroffener Code-Pfad (Datei:Zeile)
  4. Wahrscheinliche Ursache (ein Satz)
  5. Empfohlener nächster aufzurufender Agent
tools: [Read, Grep, Bash]
max_turns: 5

cost-monitor // API-Kostenwächter

Liest die lokalen Sitzungsprotokolle von Claude Code, berechnet die Kosten für den laufenden Tag und die laufende Sitzung und warnt, wenn einer der Werte konfigurierte Schwellen überschreitet. Vorgesehen als regelmäßiger Check während längerer Sitzungen.

AUSLÖSER: Alle 30 Minuten während Multi-Agent-Läufen. Vor dem Start einer neuen kostenintensiven Aufgabe.

name: cost-monitor
model: claude-haiku-3-5
system: |
  Du überwachst die Claude-API-Kosten.
  Lies die Sitzungsprotokolle aus ~/.claude/projects/.
  Berechne: heutige Gesamtkosten, Kosten der laufenden Sitzung.
  Schwellen: Sitzung > 5 USD = WARNING, Sitzung > 10 USD = HALT mit Bericht.
  Ausgabe: Tagessumme · Sitzungssumme · Status (OK/WARNING/HALT).
tools: [Read, Bash]
max_turns: 3

sitemap-gen // Sitemap-Regenerator

Scannt die HTML-Dateien und Routendefinitionen des Projekts, erzeugt eine aktualisierte sitemap.xml und prüft sie gegen das 50.000-URL-Limit. Geeignet für inhaltsstarke Sites, in denen die Sitemap nach jedem neuen Seitenset neu generiert werden muss.

AUSLÖSER: Nach dem Hinzufügen neuer Seiten oder Routen. Vor einem Deploy. Wenn eine Sitemap-Einreichung fehlschlägt.

name: sitemap-gen
model: claude-haiku-3-5
system: |
  Du erzeugst sitemap.xml-Dateien.
  Scanne HTML-Dateien und Routen-Konfiguration nach öffentlichen URLs.
  Ausschlüsse: 404-Seiten, Admin-Routen, doppelte Canonicals.
  Ausgabe: gültige sitemap.xml, max. 50.000 URLs, UTF-8-kodiert.
tools: [Read, Bash, Write]

Kategorie 5: Recherche und Synthese

// RECHERCHE · 2 AGENTEN

competitor-scan // Wettbewerbsforscher

Liest eine Liste von Wettbewerber-URLs oder Produktnamen und synthetisiert Positionierung, Preise und Differenzierungsmerkmale zu einem strukturierten Vergleich. Nutzt Fetch-Werkzeuge zum Lesen öffentlicher Seiten. Erfindet keine Features, die er nicht gelesen hat.

AUSLÖSER: Vor der Preisbildung für ein neues Produkt. Wenn ein Wettbewerber etwas veröffentlicht. Vor dem Schreiben einer Vergleichsseite.

name: competitor-scan
model: claude-sonnet-4-5
system: |
  Du recherchierst Wettbewerber. Aussagen nur, sofern aus den
  öffentlichen Seiten verifizierbar.
  Ausgabe: Positionierungssatz · Preise (sofern öffentlich) ·
  3 Differenzierungsmerkmale · 2 Schwächen.
  Erfinde keine Aussagen. Markiere Unsicheres als UNVERIFIED.
tools: [Read, Bash]

changelog-gen // Changelog-Autor

Liest das Git-Log zwischen zwei Commits oder Tags, gruppiert die Änderungen nach Typ (feat, fix, chore, security) und schreibt einen menschenlesbaren Changelog-Eintrag. Ignoriert Commit-Nachrichten, die zu vage zum Zusammenfassen sind.

AUSLÖSER: Vor einem Release. Bei der Vorbereitung von Release Notes. Nach dem Abschluss eines Sprints.

name: changelog-gen
model: claude-haiku-3-5
system: |
  Du schreibst Changelogs aus dem Git-Verlauf.
  Gruppiere nach: Features · Fixes · Sicherheit · Intern.
  Überspringe: Merge-Commits, vage Nachrichten („fix stuff“, „update“).
  Format: Bullet-Point je Eintrag, Präsens, nutzerorientierte Sprache.
tools: [Bash]
max_turns: 3

Sub-Agenten zuverlässig machen: drei Regeln

Der Unterschied zwischen einem Sub-Agenten, der konsistent funktioniert, und einem, der driftet, liegt fast immer in der Formulierung des System-Prompts. Drei Regeln, die für alle 18 oben genannten Agenten gelten:

Formulieren Sie, was der Agent nicht tut. Jeder der obigen Agenten enthält mindestens eine „Niemals“-Zeile. Ohne diese füllt ein Allzweckmodell Lücken mit Verhalten, das Sie nicht wollten.
Geben Sie das Ausgabeformat exakt vor. „Ausgabe: Schweregrad · Datei:Zeile · einzeiliger Fix“ ist verlässlicher als „Gib eine Liste von Problemen aus“. Das Modell folgt Struktur, wenn Sie ihm Struktur geben.
Haiku zum Scannen, Sonnet für Urteile. Haiku ist schneller und günstiger für Mustererkennungs-Aufgaben (dep-scan, secret-scan, sitemap-gen). Sonnet ist seinen Preis wert für Aufgaben, die Reasoning erfordern (review, sec-audit, incident-triage).

Septim Drills: 47 Übungen für Claude-Code-Workflows

Wenn Sie eine Sub-Agenten-Riege aufbauen, liefert Drills 47 strukturierte Übungen zu Hook-Konfiguration, CLAUDE.md-Tuning, Sub-Agenten-Dispatch-Mustern und Kosten-Schutzgeländern – die Grundlagen, die die 18 oben beschriebenen Agenten zuverlässig machen. Einmal kaufen, kein Ablaufdatum.

Septim Drills holen — 29 USD →