Beste Claude Code Subagents 2026 (und wie du deine eigenen baust)
Die nützlichsten Claude Code Subagents, die du 2026 einrichten solltest: Planer-, Reviewer-, Tester-, Security- und Debugger-Rollen, plus eine Schritt-für-Schritt-Anleitung, wie du deinen eigenen Subagent schreibst.
Hören Sie auf zu konfigurieren. Fangen Sie an zu bauen.
SaaS-Builder-Vorlagen mit KI-Orchestrierung.
Die besten Claude Code Subagents sind fokussierte Rollen, an die du delegierst: ein Planer, ein Code-Reviewer, ein Tester, ein Debugger und ein Rechercheur. Jeder läuft in seinem eigenen Kontext mit seinen eigenen Tools, macht eine Aufgabe gut und gibt ein sauberes Ergebnis zurück, ohne deine Hauptsitzung zu fluten. Du definierst sie als Markdown-Dateien in deinem .claude/agents/ Ordner, und du kannst deine eigenen in ein paar Minuten schreiben.
Diese Anleitung reiht die Rollen, die sich zuerst einzurichten lohnen, und zeigt dir dann genau, wie du einen eigenen baust.
Was ein Subagent eigentlich ist
Ein Subagent ist ein spezialisierter Agent, dem die Haupt-Claude-Code-Sitzung eine Aufgabe übergeben kann. Er hat seine eigenen Anweisungen, seine eigenen erlaubten Tools und sein eigenes frisches Kontextfenster. Wenn der Hauptagent delegiert, arbeitet der Subagent, gibt eine letzte Nachricht zurück, und seine Zwischen-Tool-Ausgabe bleibt aus deiner Hauptkonversation heraus.
Dieser letzte Teil ist der echte Gewinn. Eine lange Suche oder ein lauter Testlauf kann deinen Hauptkontext auffressen. Ein Subagent schluckt diesen Lärm und reicht nur die Schlussfolgerung zurück. Zur tieferen Design-Begründung siehe Subagent-Design und Subagent-Best-Practices.
Die 5 Subagents, die sich zuerst einzurichten lohnen
| Subagent | Aufgabe | Warum er sich verdient |
|---|---|---|
| Planer | Ein Feature in geordnete Schritte zerlegen | Verhindert, dass der Hauptagent halb blind losstürmt |
| Code-Reviewer | Den Diff auf Bugs und Sicherheitsprobleme prüfen | Ein frischer, skeptischer Durchlauf fängt, was der Autor übersah |
| Tester | Tests für neuen Code schreiben und ausführen | Verifiziert die Arbeit, statt ihr zu vertrauen |
| Debugger | Einen Fehler reproduzieren und isolieren | Hält langes, lautes Debugging aus dem Hauptkontext |
| Explorer | Die Codebasis oder das Web durchsuchen, Zusammenfassung zurückgeben | Liest viele Dateien, reicht nur die Antwort zurück |
1. Der Planer
Ein Planer nimmt eine Feature-Anfrage und gibt einen geordneten, Schritt-für-Schritt-Bauplan zurück: was zu ändern ist, in welcher Reihenfolge, und was wovon abhängt. Du lässt ihn laufen, bevor irgendein Code geschrieben wird. Er hält den Hauptagenten davon ab, ohne Landkarte in eine große Aufgabe zu stürmen. Kombiniere ihn mit spec-getriebener Entwicklung für die stärksten Ergebnisse.
2. Der Code-Reviewer
Ein Reviewer liest den Diff mit einer Aufgabe: Bugs, Sicherheitslücken und schlampige Muster finden. Der Trick ist, dass er mit frischen Augen und einem skeptischen Prompt reviewt, also nicht von der Überlegung beeinflusst ist, die den Code erzeugt hat. Gib ihm read-only Tools und einen Prompt, der ihm sagt, im Zweifel alles Unsichere zu markieren.
3. Der Tester
Ein Tester schreibt Tests für neuen Code und führt sie aus, dann meldet er bestanden oder durchgefallen. Das zu delegieren hält den Verifizier-Schritt ehrlich: Der Agent, der das Feature schrieb, ist nicht der, der es benotet. Testläufe sind außerdem laut, also genau die Art von Ausgabe, die ein Subagent schlucken sollte.
4. Der Debugger
Wenn etwas kaputtgeht, reproduziert ein Debugger-Subagent den Fehler, grenzt ihn ein und meldet die Ursache. Debugging verbrennt viele Tool-Aufrufe und Sackgassen, also schützt es deine Hauptsitzung vor dem Durcheinander, es in einem Subagent zu isolieren, während das Problem trotzdem gelöst wird.
5. Der Explorer
Ein Explorer durchsucht deine Codebasis (oder das Web), um eine Frage zu beantworten, und gibt eine kurze Zusammenfassung zurück, statt jede Datei abzuladen, die er gelesen hat. Wenn Antworten heißt, viele Dateien zu durchforsten, ist das der Subagent, der die Schlussfolgerung behält und den Lärm wegwirft. Siehe Aufgabenverteilung, wie du mehrere davon auf einmal ausfächerst.
Wie du deinen eigenen Subagent baust
Ein Subagent ist einfach eine Markdown-Datei in .claude/agents/. Hier ist ein vollständiger, funktionierender Code-Reviewer, den du direkt einsetzen kannst.
---
name: code-reviewer
description: Reviews the current diff for bugs, security issues, and risky patterns. Use after writing or editing code, before committing.
tools: Read, Grep, Glob, Bash
---
You are a skeptical senior code reviewer. Review only the current diff.
Focus, in order:
1. Correctness bugs that would break at runtime.
2. Security issues: missing auth checks, unsafe input handling, leaked secrets, missing row-level security.
3. Risky patterns: duplicated logic, swallowed errors, untested edge cases.
Rules:
- Default to flagging anything you are unsure about.
- Quote the file and line for every finding.
- Do not rewrite the code. Report findings only.
Your final message is the review. Return a short list of findings, each with file, line, severity, and a one-line fix. If the diff is clean, say so plainly.Das Frontmatter macht drei Dinge. name ist die ID des Agenten. description sagt der Hauptsitzung, wann sie an ihn delegieren soll, also schreib sie als Auslöser ("use after writing code"). tools begrenzt, was er anfassen kann; ein Reviewer muss nur lesen und suchen, also bekommt er keinen Schreibzugriff.
Der Body ist der System-Prompt. Halte die Rolle schmal, liste die Regeln, und schließe damit, dem Agenten zu sagen, dass seine letzte Nachricht der Rückgabewert ist, sodass er ein sauberes Ergebnis zurückgibt statt einer geschwätzigen Zusammenfassung. Mehr dazu in Custom Agents.
Drei Regeln für gute Subagents
- Eine Aufgabe pro Stück. Ein Subagent, der zwei Dinge macht, macht beide schlechter. Teil ihn auf.
- Wenigste Tools. Gib ihm nur die Tools, die die Aufgabe braucht. Ein Reviewer, der keinen Code schreiben kann, kann ihn nicht aus Versehen ändern.
- Saubere Rückgaben. Schreib den Prompt so, dass die letzte Nachricht genau die Daten sind, die die Hauptsitzung will, nicht ein Absatz darüber, was er gemacht hat.
Mach die richtig, und deine Hauptsitzung bleibt klar, während fokussierte Subagents die schwere, laute Arbeit erledigen. Zum Koordinieren mehrerer auf einmal lies Agent Teams Best-Practices. Zum Unterschied zwischen einem Subagent und einer geforkten Sitzung siehe Claude Code Fork und Subagent.
Aus einem vorgebauten Set starten
Wenn du lieber nicht jeden Subagent von Grund auf schreiben willst, bündeln Community-Sammlungen wie VoltAgents awesome-claude-code-subagents Dutzende Rollendefinitionen, die du installieren und anpassen kannst. Und wenn dein Ziel ist, ein Produkt auszuliefern, ist Build This Now ein einmaliges Claude Code Kit für $29, das Spezialisten-Agents und einen Produktiv-Stack zusammen liefert, sodass die Planungs-, Bau- und Test-Rollen schon rund um Auth, Bezahlung und eine sichere Datenbank verdrahtet sind.
FAQ
Was ist ein Claude Code Subagent?
Ein Subagent ist ein spezialisierter Agent mit eigenen Anweisungen, Tools und Kontextfenster, an den die Hauptsitzung eine Aufgabe delegiert. Er macht seine Aufgabe, gibt ein Ergebnis zurück und hält seine laute Tool-Ausgabe aus der Hauptkonversation heraus. Subagents werden als Markdown-Dateien in deinem .claude/agents/ Ordner definiert.
Wie erstelle ich einen eigenen Subagent in Claude Code?
Erstelle eine Markdown-Datei in .claude/agents/ mit Frontmatter für Name, Beschreibung und erlaubte Tools, gefolgt von einem System-Prompt, der seine Rolle und Regeln beschreibt. Halte ihn schmal, gib ihm nur die Tools, die er braucht, und schreib den Prompt so, dass seine letzte Nachricht genau das Ergebnis zurückgibt, das du willst.
Welche Claude Code Subagents lohnen sich am meisten einzurichten? Ein Planer, ein Code-Reviewer, ein Tester, ein Debugger und ein Rechercheur oder Explorer. Diese decken die Teile des Bauens ab, wo ein frischer, fokussierter Kontext eine überladene Sitzung schlägt.
Wie viele Subagents sollte ich laufen lassen? Richte zuerst die fünf Kern-Rollen ein, dann füg nur mehr hinzu, wenn eine echte, wiederkehrende Aufgabe es rechtfertigt. Jeder Subagent sollte eine klare Aufgabe haben; ein Haufen überlappender Agents ist schwerer zu managen als ein paar scharfe.
Hören Sie auf zu konfigurieren. Fangen Sie an zu bauen.
SaaS-Builder-Vorlagen mit KI-Orchestrierung.
Agent-Harness-Engineering
Der Harness ist jede Schicht rund um deinen KI-Agenten, außer dem Modell selbst. Lern die fünf Steuerungshebel, das Constraint-Paradoxon und warum das Harness-Design die Performance des Agenten mehr bestimmt als das Modell.
Prompt-Vorlagen, die Code liefern
Zehn Prompt-Rezepte, die Code liefern: Full-Stack-Scaffolding, APIs, Schemas, Tests, Refactoring, Debugging, Reviews und CI. Jeweils mit den Fehlermodi, die es zu vermeiden gilt.