Agent Teams Prompt-Templates

Problem: Agent Teams ist aktiviert, und "starte ein Team für mein Projekt" ergibt ein Chaos. Der Unterschied zwischen einem effizienten Team und einem Token-Brand liegt darin, wie der Prompt formuliert ist. Ein produktives Team hat spezifische Rollen, klare Dateigrenzen und eine definierte Ziellinie. Ein schlechtes hat drei Reviewer, die überlappende Arbeit machen.

Schneller Gewinn: Probiere zuerst den parallelen Code-Review-Prompt (Muster Nr. 1 unten). Es ist das am breitesten nutzbare Agent Teams-Muster und läuft auf jeder Codebasis. Drei Reviewer, drei Linsen, ein zusammengefasstes Review. Du siehst die Ausgabe in Minuten, und es fängt Dinge auf, die ein einzelner Reviewer übersehen hätte.

Dies ist ein Begleiter zur Agent Teams-Übersicht. Fang dort an, wenn du dein erstes Team noch nicht eingerichtet hast. Für Steuerung und Konfiguration spring zu Advanced Controls. Die zehn Prompts unten decken die Workflows ab, wo parallele Ausführung mit aktiver Koordination serielle Arbeit schlägt.

Code-Team-Muster

1. Paralleles Code-Review

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings. Use delegate mode so the
lead synthesizes a final review without doing its own analysis.

Warum es funktioniert: Ein Reviewer driftet zu einer Art von Problem auf einmal. Die Kriterien in unabhängige Domänen aufzuteilen bedeutet, dass Sicherheit, Performance und Testabdeckung jeweils einen vollständigen Durchlauf gleichzeitig bekommen. Der Lead näht alles zu einem Review zusammen, das Probleme auffängt, die kein einzelner Reviewer erkennen würde. Drei-Reviewer-Teams finden konsistent Probleme, die Einzel-Review-Durchläufe übersehen. Erwarte ungefähr 2-3x die Token-Kosten eines Einzel-Sitzungs-Reviews. Es lohnt sich für die Abdeckung.

Delegate-Modus ist wichtig. Ohne ihn neigt der Lead dazu, sein eigenes Review durchzuführen und es unbeholfen mit den Ergebnissen der Teamkollegen zu vermischen. Mit aktivem Delegate-Modus konzentriert sich der Lead vollständig auf Koordination und Synthese.

2. Debugging mit konkurrierenden Hypothesen

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk
to each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

Warum es funktioniert: Eine Debattenstruktur schlägt Anker-Bias. Sequentielle Untersuchung bleibt an der ersten plausiblen Theorie hängen und versucht, sie zu bestätigen. Mehrere unabhängige Ermittler, die aktiv versuchen, gegenseitige Theorien zu widerlegen, bedeuten, dass die überlebende Theorie näher an der echten Ursache ist.

Dieses Muster fördert auch unerwartete Verbindungen. Wenn Teamkollege Nr. 3 ein Memory-Leak findet und Teamkollege Nr. 1 Timeout-Verhalten verfolgte, können sie die Punkte direkt verbinden. Kein Lead in der Mitte. Dieser direkte Kanal trennt Agent Teams von Sub-Agenten-Mustern.

3. Full-Stack-Feature-Implementierung

Create an agent team to implement the user notifications system.
Spawn four teammates:
- Backend: Create the notification service, database schema, and API endpoints
- Frontend: Build the notification bell component, dropdown, and read/unread states
- Tests: Write integration tests for the full notification flow
- Docs: Update the API documentation and add usage examples

Assign each teammate clear file boundaries. Backend owns src/api/notifications/
and src/db/migrations/. Frontend owns src/components/notifications/.
Tests own tests/notifications/. No file overlap.

Warum es funktioniert: Dateigrenzen auf Verzeichnisebene eliminieren Merge-Konflikte. Jeder Teamkollege weiß, welche Verzeichnisse er besitzt, und die gemeinsame Aufgabenliste hält alle auf dem gleichen Stand. In dem Moment, in dem der Backend-Teamkollege den API-Vertrag landet, holt ihn der Frontend-Teamkollege ab. Beide beobachten dieselbe Liste.

Ohne explizite Grenzen werden zwei Teamkollegen dieselbe Datei bearbeiten und aufeinanderprallen. Besitz auf Verzeichnisebene ist das wichtigste Detail in einem Implementierungs-Prompt. Dieses Muster bildet direkt das Wave-Execution-Modell im Workflow-Leitfaden ab, wo vorgelagerte Verträge in parallele Agenten-Start-Prompts einfließen.

4. Architecture Decision Record

Create an agent team to evaluate database options for our new analytics feature.
Spawn three teammates, each advocating for a different approach:
- Teammate 1: Argue for PostgreSQL with materialized views
- Teammate 2: Argue for ClickHouse as a dedicated analytics store
- Teammate 3: Argue for keeping everything in the existing MongoDB

Have them challenge each other's arguments. Focus on: query performance
at 10M+ rows, operational complexity, migration effort, and cost.
The lead should synthesize a decision document with the strongest arguments
from each side.

Warum es funktioniert: Deliberation schlägt einen einzelnen Agenten, der Optionen eigenständig abwägt. Jeder Teamkollege verpflichtet sich zu einer Position und sucht nach Rissen in den anderen. Der Lead schreibt nur die Argumente auf, die die Herausforderung überstanden haben.

Das ist besonders nützlich für Entscheidungen, bei denen jede Option echte Trade-offs hat und keinen offensichtlichen Gewinner. Eine einzelne Sitzung neigt dazu, früh eine zu wählen und sie zur Antwort zu rationalisieren. Die adversariale Struktur erzwingt echte Bewertung jeder Alternative.

5. Engpassanalyse

Create an agent team to identify performance bottlenecks in the application.
Spawn three teammates:
- One profiling API response times across all endpoints
- One analyzing database query performance and indexing
- One reviewing frontend bundle size and rendering performance

Have them share findings when they discover something that affects
another teammate's domain (e.g., slow API caused by missing DB index).

Warum es funktioniert: Domänenübergreifende Kommunikation ist der Ort, wo Agent Teams Sub-Agenten schlagen. Wenn der Datenbankanalyst einen fehlenden Index entdeckt, der den langsamen Endpunkt des API-Teamkollegen erklärt, gibt er es direkt weiter. Sub-Agenten können das nicht, weil Sub-Agenten nur an die Hauptsitzung zurückmelden und nie miteinander reden.

Eine Performance-Suche profitiert auch von der gemeinsamen Aufgabenliste. Während jeder Teamkollege Probleme mit Schweregradbewertungen protokolliert, sieht der Lead das Bild in Echtzeit entstehen und lenkt Bemühungen auf die schlimmsten Täter um.

6. Inventarklassifizierung

Create an agent team to classify our product catalog. We have 500 items
that need categorization, tagging, and description updates.
Spawn 4 teammates, each handling a segment:
- Teammate 1: Items 1-125
- Teammate 2: Items 126-250
- Teammate 3: Items 251-375
- Teammate 4: Items 376-500

Use the classification schema in docs/taxonomy.md. Have teammates
flag edge cases for the lead to review.

Warum es funktioniert: Datenparallele Arbeit skaliert linear mit Teamkollegen. Jeder arbeitet unabhängig durch sein Segment und markiert mehrdeutige Elemente für einen menschlichen Durchlauf. Vier Teamkollegen, die je 125 Elemente verarbeiten, landen ungefähr 4x schneller als eine Sitzung, die 500 verarbeitet.

Das gleiche Muster passt zu jeder Massenoperation. Support-Tickets taggen, Dokumentationsseiten kategorisieren, Datenbankeinträge normalisieren, CSV-Dateien durcharbeiten. Der Schlüssel ist, nach Datengrenzen aufzuteilen, nicht nach Funktion.

Nicht-Code-Team-Muster

Agent Teams sind nicht nur für Code. Alles, das von parallelen Perspektiven und enger Koordination profitiert, kommt in Frage. Die Prompts unten decken Recherche, Content und Kampagnenstrategie ab.

7. Kampagnenrecherche-Sprint

Create an agent team to research the launch strategy for [product].
Spawn three teammates:
- Competitor analyst: study competitor ad copy, positioning, and pricing
- Voice of customer researcher: mine reviews, Reddit threads, and forums
  for pain points and language customers actually use
- Positioning stress-tester: take findings from both teammates and
  pressure-test our current positioning against what they discover

Have them share findings and challenge each other. The lead synthesizes
a strategy document with positioning recommendations.

Warum es funktioniert: Der Wettbewerbs-Rechercheur findet Marktlücken. Der Voice-of-Customer-Teamkollege prüft, ob echte Käufer sich tatsächlich um diese Lücken sorgen. Der Positioning-Stress-Tester nimmt beide Inputs und versucht, deine Botschaft damit zu brechen. Drei Linsen, eine Synthese, jede Ausgabe des Teamkollegen füttert die anderen.

Vergleiche das mit drei separaten Recherche-Sitzungen. Du würdest mit drei unabhängigen Berichten enden und dann Zeit damit verbringen, sie manuell zu vergleichen. Agent Teams machen den Quervergleich automatisch durch Inter-Agenten-Messaging.

8. Landing Page Build mit adversarialem Review

Create an agent team to build the landing page for [offer].
Spawn three teammates:
- Copywriter: develop messaging, headlines, and body copy
- CRO specialist: design conversion structure, CTA placement, and flow
- Skeptical buyer: review everything as a resistant prospect, flag
  weak claims, missing proof, and friction points

Require plan approval before any implementation.

Warum es funktioniert: Plan-Genehmigung fängt schlechte Richtungen auf, bevor sie Zyklen verbrennen. Der adversariale Reviewer findet Lücken, an denen die auf-den-Builder-fokussierten Teamkollegen vorbeischlüpfen. Echte Käufer sind skeptisch. Dein Team sollte es auch sein.

Plan-Genehmigung ist hier am wichtigsten, weil Landing-Page-Text teuer umzuschreiben ist. Eine schwache Value-Proposition in der Gliederungsphase zu erkennen dauert Minuten. Sie nach einem vollständigen Build zu erkennen dauert Stunden.

9. Ad Creative Exploration

Spawn 4 teammates to explore different hook angles for [product].
Each teammate develops one direction with headline variations,
supporting copy, and a rationale for why the angle works.
Have them debate which direction is strongest.
Update findings doc with consensus and runner-up options.

Warum es funktioniert: Ein Agent, der allein erkundet, verankert sich an der ersten guten Idee. Vier Agenten, die aktiv versuchen, sich gegenseitig zu übertreffen, produzieren kampferprobte Creatives. Die Debattenstruktur bedeutet, dass der gewinnende Winkel eine echte Herausforderung überlebt hat, nicht den internen Monolog einer einzelnen Sitzung.

Dieses Muster produziert Winkel, die keine Einzelsitzung erkundet hätte. Wenn Teamkollege Nr. 2 den Ansatz von Teamkollege Nr. 1 herausfordert, verfeinert Teamkollege Nr. 1 seinen Winkel oft in etwas Stärkeres, statt ihn fallen zu lassen. Wettbewerbsdruck hebt den Qualitätsboden.

10. Content-Produktions-Pipeline

Create a team for this week's content calendar.
Spawn three teammates:
- Researcher: identify search intent gaps and competitive opportunities
- Writer: draft content based on research findings
- Quality reviewer: run each piece through clarity, proof, and SEO checks

Chain tasks so the researcher finishes before the writer starts,
and the reviewer checks each piece before marking it complete.

Warum es funktioniert: Parallele Recherche und sequentielle Qualitätsgates. Der Rechercheur und der Writer können sich bei verschiedenen Stücken überlappen, während der Reviewer Probleme abfängt, bevor etwas veröffentlicht wird. Eingebautes QA ohne separaten Review-Prozess.

Aufgaben-Verkettung ist das entscheidende Detail. Ohne sie starten alle drei Teamkollegen gleichzeitig und der Writer entwirft blind ohne Recherche. Explizite Aufgaben-Abhängigkeiten durch die gemeinsame Aufgabenliste erzwingen die richtige Ausführungsreihenfolge. Mehr zur Verkettung von Aufgaben über Agenten hinweg findest du in den Async-Workflows.

Ein Drei-Wochen-Einstieg

Neu bei Agent Teams? Fang einfach an und baue auf. Direkt in einen Fünf-Teamkollegen-Implementierungs-Prompt zu springen ist ein Rezept für Verwirrung. Diese Drei-Wochen-Progression baut Intuition auf, wann Teams Mehrwert schaffen und wann sie Overhead hinzufügen.

Woche 1: Recherche und Review

Nimm einen PR, der Review braucht. Aktiviere Agent Teams, dann führe aus:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

Drei Reviewer, drei Linsen, ein Review. Du wirst sehen, wie Teamkollegen die Aufgabenliste durcharbeiten, Erkenntnisse austauschen und Ergebnisse liefern. Geringes Risiko, hohe Lernkurve. Im schlimmsten Fall bekommst du ein unvollständiges Review, das du manuell fertigstellst.

Woche 2: Debugging mit Debatte

Nimm einen Bug-Report und führe das Konkurrierende-Hypothesen-Muster aus:

Users report intermittent 500 errors on the checkout endpoint.
Spawn 3 teammates to investigate different hypotheses:
- One checking database connection pooling
- One investigating race conditions in the payment flow
- One analyzing server resource limits
Have them share findings and challenge each other's theories.

Das lehrt dich, wie Inter-Agenten-Kommunikation in der Praxis funktioniert. Beobachte, wie Teamkollegen Beweise teilen, wie sie schwache Theorien zurückweisen und wie sich Konsens bildet. Die gemeinsame Aufgabenliste ist der Ort, wo der Großteil dieser Koordination sichtbar wird.

Woche 3: Implementierung

Sobald sich die Koordinationsmuster natürlich anfühlen, probiere einen Feature-Build mit klaren Dateigrenzen:

Create an agent team to build the webhook system.
Assign directory-level ownership to prevent conflicts.
Use delegate mode for the lead.

In Woche drei wirst du ein Gespür dafür haben, wann sich Teams bezahlt machen und wann ein Einzel-Sitzungs- oder Sub-Agenten-Ansatz die bessere Wahl ist. Die meisten Entwickler stellen fest, dass Teams am besten für Aufgaben funktionieren, die drei oder mehr unabhängige Arbeitsströme mit mindestens etwas domänenübergreifender Kommunikation benötigen.

Was wirklich funktioniert

Nach Dutzenden von Agent-Teams-Sitzungen halten diese Muster über jeden Workflow oben stand:

• Sei spezifisch bei Rollen: "einer für Sicherheit, einer für Performance" schlägt "Reviewer". Vage Rollen produzieren vage Arbeit.
• Definiere Dateigrenzen: Besitz auf Verzeichnisebene eliminiert Merge-Konflikte. Nicht verhandelbar für Implementierungsaufgaben.
• Füge Erfolgskriterien ein: "Erkenntnisse berichten" oder "das Entscheidungsdokument aktualisieren" gibt jedem Teamkollegen eine Ziellinie.
• Verwende Delegate-Modus für reine Koordination: Verhindert, dass der Lead die Arbeit selbst erledigt. Die Aufgabe des Leads ist Synthese, nicht Produktion.
• Verlange Plan-Genehmigung für riskante Arbeit: Fängt schlechte Richtungen auf, bevor sie Token verbrennen. Kritisch für kreative und Implementierungsaufgaben.
• Lass Teamkollegen streiten: Reibung schlägt Einigkeit. Debattenmuster übertreffen konsensuchende konsistent.
• Halte Teamgröße bei 3-5: Mehr Teamkollegen bedeutet mehr Koordinations-Overhead und höhere Token-Kosten. Ab fünf frisst das Kommunikationsvolumen den Parallelitätsgewinn.
• Passe das Muster der Aufgabe an: Datenparallele Arbeit (Klassifizierung, Verarbeitung) teilt nach Datengrenzen. Funktionale Arbeit (Feature-Implementierung) teilt nach Domäne. Bewertende Arbeit (Architekturentscheidungen, Kreatives) teilt nach Perspektive.
• Beschleunige den Lead mit Fast Mode: Schalte Fast Mode für den Lead für schnellere Koordination ein, während Teamkollegen mit Standardgeschwindigkeit laufen, um Kosten zu senken.

Für Best Practices, Troubleshooting und bekannte Einschränkungen sieh dir Agent Teams Best Practices an. Für Anzeigemodi, Token-Kostenmanagement und Qualitätsgate-Hooks sieh dir Advanced Controls an.

Diese Prompts funktionieren so wie sie sind für jeden Claude Code-Nutzer mit aktiviertem Agent Teams. Starte diese Woche mit dem Code-Review-Prompt. Der Overhead ist gering, und jeder Prompt oben ist ein getesteter Ausgangspunkt für einen Workflow, den du bereits ausführst.