Agenten anlegen – Templates als Abkürzung oder selbst scaffolden

In den vorherigen Posts dieser Serie habe ich viel darüber geschrieben, was Agenten tun – welche Rollen sie übernehmen, warum die Trennung in Planungs- und Implementierungsagenten sinnvoll ist, und wie der Human-in-the-Loop-Checkpoint die Qualität sichert. Was ich bisher nur am Rand erwähnt habe: wie diese Agenten überhaupt entstehen. Wie man sie anlegt, für das eigene Projekt anpasst – und welcher Weg sich wann lohnt.

Das ist der Fokus dieses Posts.

Zwei Wege zum eigenen Agenten-Team

Es gibt zwei sinnvolle Wege, einen Agenten in Claude Code oder GitHub Copilot aufzusetzen. Beide funktionieren, beide haben ihre Berechtigung – und beide laufen am Ende auf dieselbe Markdown-Datei hinaus.

Weg A: Templates als Ausgangspunkt. Eine fertige Agenten-Definition aus einem öffentlichen Repository in das eigene Projekt kopieren und für die eigene Codebase anpassen.

Weg B: Von Grund auf scaffolden. Den eingebauten /agents-Befehl in Claude Code oder /create-agent-Skill in GitHub Copilot nutzen, um eine leere Agenten-Datei aus einer Rollenbeschreibung zu generieren – und sie dann fein zuschneiden.

Welcher Weg besser ist, hängt davon ab, ob man eine ähnliche Rolle schon einmal gesehen hat. Ich nutze beide – und kombiniere sie auch.

Weg A: Templates als Abkürzung

Für die vier Rollen, die ich in den vorherigen Posts beschrieben habe – Business Analyst, Solution Architect, Realisierungsplan-Agent und Developer-Agent – habe ich meine eigenen Agenten-Definitionen als Templates auf GitHub veröffentlicht. Sie sind die direkte Verschriftlichung dessen, was ich in meinen Projekten täglich nutze – inklusive der Pfadkonventionen, der Dokumentstrukturen und der expliziten Grenzen, die jeder Agent einhalten muss.

Der Vorteil dieses Wegs ist offensichtlich: Man bekommt nicht nur eine Rollenbeschreibung, sondern auch die strukturellen Entscheidungen mitgeliefert, die ich in den vorherigen Posts beschrieben habe – das Ablageformat für Use Cases, die Schritt-Struktur des Realisierungsplans mit Validierung und Cleanup, die explizite Grenze des Solution Architects, keinen Code zu schreiben.

Der Nachteil ist genauso offensichtlich, und ich möchte ihn nicht beschönigen: Ein Template ist niemals ein fertiges Setup.

Die Pfade in den Templates zeigen auf docs/usecases/, docs/loesungskonzept/ und docs/plan/. Das funktioniert, wenn man bereit ist, diese Konventionen zu übernehmen – oder man passt es an. Die Validierungsbefehle im Realisierungsplan-Template sind auf npm run build und flutter analyze zugeschnitten. Die referenzierten Coding-Guidelines sind meine. Wer den Solution Architect für ein Java-Backend nutzen will, wird in der Maßnahmen-Tabelle andere Schichten brauchen als für ein Flutter-Frontend.

Templates nehmen einem also die Rohfassung ab – sie nehmen einem nicht die Verantwortung ab, sie für das eigene Projekt scharfzustellen.

Wie ich vorgehe, wenn ich ein Template nutze

Mein Ablauf ist immer derselbe:

1. Die Template-Datei in mein .claude/agents/-Verzeichnis kopieren – möglichst unter dem Namen, den ich im Prompt nutzen will (business-analyst.md, solution-architect.md, …).
2. Die Pfade darin durchsuchen und auf meine Verzeichnisstruktur anpassen.
3. Die Verweise auf Coding-Guidelines so umbiegen, dass sie auf die Datei in meinem Repo zeigen – nicht auf die GitHub-Variante.
4. Die explizit beschriebenen Handoffs prüfen: erwartet der Agent als Eingabe wirklich das Format, das mein vorgelagerter Agent produziert?
5. Erst dann den Agenten zum ersten Mal mit einem kleinen, isolierten Use Case einsetzen – und nachschärfen, was sich im Praxiseinsatz zeigt.

Das dauert pro Template typischerweise zehn bis zwanzig Minuten. Es ist nicht null Aufwand, aber es ist deutlich weniger, als denselben Agenten von Grund auf zu durchdenken.

Weg B: Von Grund auf scaffolden

Wenn ich eine Rolle brauche, für die kein Template existiert – etwa einen Code-Reviewer mit Sicherheitsfokus oder einen Migrations-Agenten für eine spezifische Bibliothek – nehme ich den zweiten Weg. Beide Tools, die ich nutze, bringen dafür einen eigenen Befehl mit.

Claude Code: /agents

Claude Code bringt von Haus aus eine Möglichkeit mit, neue Agenten anzulegen: den /agents-Befehl. Wenn man ihn aufruft, führt Claude Code durch einen geführten Prozess – fragt nach Name, Rolle und Verhalten des Agenten – und legt am Ende eine fertige .md-Datei im .claude/agents/-Verzeichnis des Projekts ab.

Das Ergebnis ist ein guter erster Entwurf. Aber es ist nur ein Entwurf.

Was /agents nicht weiß: wie meine Codebase aufgebaut ist. Welche Konventionen ich in meinen Vue-Komponenten verwende. Dass meine Agenten ihre Ergebnisse in bestimmten Verzeichnissen ablegen sollen. Dass es einen Solution Architect gibt, dessen Lösungskonzept der Realisierungsplan-Agent als Eingabe erwartet. Diese Verbindungen existieren im frisch generierten Agenten nicht – sie müssen nachträglich eingearbeitet werden.

Das ist für mich keine Enttäuschung, sondern eine klare Arbeitsteilung: /agents übernimmt das Scaffolding. Das projektspezifische Fine-Tuning übernehme ich.

GitHub Copilot: /create-agent

GitHub Copilot hat seinen eigenen Weg, Agenten anzulegen: den eingebauten /create-agent-Skill im Copilot Chat. Man ruft ihn auf, beschreibt die gewünschte Rolle, und Copilot erstellt daraus eine .agent.md-Datei mit derselben Grundstruktur, die auch die Claude-Agenten haben – Rollenbeschreibung, Verhalten, Grenzen.

Meine Erfahrung: Das funktioniert – aber mit einer Einschränkung, die ich erst herausfinden musste.

Die Qualität des erzeugten Agenten hängt stark vom Modell ab, mit dem man /create-agent aufruft. Wenn Copilot einem die Wahl lässt, würde ich empfehlen, dabei bewusst auf ein OpenAI-Modell zu wechseln. Nicht weil die anderen Modelle grundsätzlich schlechter wären – sondern weil Copilot in diesem spezifischen Anwendungsfall mit den OpenAI-Modellen konsistentere Ergebnisse geliefert hat. Die Agenten-Definitionen waren präziser, die Rollenbeschreibungen klarer, die Grenzen schärfer gezogen.

Das ist ein konkreter Handgriff, der einen Unterschied macht – und den ich nirgends dokumentiert gefunden habe. Nur durch Ausprobieren.

GitHub beschreibt das Konzept in der offiziellen Dokumentation unter Creating custom agents via Markdown – eine lesbare Einführung, die zeigt, wie Rollen strukturiert und Verhalten definiert werden. Was dort fehlt, ist das Fine-Tuning für eine konkrete Codebase. Das ist Handarbeit, egal welches Tool man nutzt.

Der Trick für Copilot: Templates per Copilot übersetzen lassen

Was passiert eigentlich, wenn ich ein Claude-Code-Template für GitHub Copilot nutzen will? Die Templates aus dem GitHub-Repository sind auf Claude-Code-Agenten zugeschnitten – Frontmatter, Tool-Referenzen, die Art, wie Rückfragen formuliert werden, folgen Claude-Konventionen. Eins zu eins in eine .agent.md zu kopieren funktioniert, aber das Ergebnis ist nicht optimal.

Hier ist der Kniff, den ich mir angewöhnt habe: Das Claude-Template als Vorlage nehmen und GitHub Copilot bitten, es nach den Best Practices für Copilot anzupassen.

Der Prompt sieht ungefähr so aus:

„Hier ist ein Agenten-Template, das ursprünglich für Claude Code geschrieben wurde. Bitte passe es nach den Best Practices für GitHub-Copilot-Agenten an. Behalte die fachliche Rolle, die Pfadkonventionen und die expliziten Grenzen bei – aber übersetze Struktur, Frontmatter und Tool-Referenzen in das, was Copilot erwartet."

Dafür wechsele ich Copilot bewusst auf ein älteres Modell – konkret GPT-5.5 oder älter. Die neueren Modelle interpretieren die Aufgabe gerne zu kreativ und schreiben die Rolle inhaltlich um. Die älteren Modelle halten sich strenger an die Vorgabe „nur das Format anpassen" – und genau das will ich an dieser Stelle.

Das Ergebnis ist eine Copilot-Variante des Agenten, die fachlich identisch zu meiner Claude-Version ist, aber im Tool-Idiom des jeweiligen Tools spricht. Ich muss die Rolle nicht zweimal denken – ich muss sie nur einmal in die richtige Form bringen lassen.

Drei Dinge, die jeden Agenten erst einsatzfähig machen

Egal ob ich ein Template als Ausgangspunkt nutze oder mit /agents bzw. /create-agent scaffolde – bevor ein Agent in meinen Workflow einzieht, schaue ich auf drei Dinge.

Erstens der Kontext. Weiß der Agent, wo er sich befindet? Kennt er die Verzeichnisstruktur, die Dokumentationspfade, die bestehenden Artefakte, auf die er aufbauen soll? Ein Business Analyst, der nicht weiß, dass fertige Use Cases unter docs/usecases/ landen sollen, legt sie irgendwo ab – oder erfindet eine eigene Konvention.

Zweitens die Handoffs. Weiß der Agent, wer vor ihm gearbeitet hat und wer nach ihm kommt? Der Realisierungsplan-Agent bekommt kein freies Konzept – er bekommt das spezifische Ausgabeformat des Solution Architects. Diese Erwartung muss explizit im Agenten beschrieben sein.

Drittens die Grenzen. Was soll der Agent explizit nicht tun? Ein Solution Architect, dem ich nicht explizit verbiete, Code zu schreiben, fängt irgendwann an, es zu versuchen. Eine Zeile „Du schreibst keinen Implementierungscode" verhindert das zuverlässiger als jede nachträgliche Formulierung im Prompt.

Das klingt nach Kleinkram. In der Praxis ist es der Unterschied zwischen einem Agenten, der meinen Workflow unterstützt, und einem, der seinen eigenen Workflow erfindet. Die Templates aus meinem Repo haben diese drei Bereiche bereits ausgefüllt – aber mit meinen Werten. Wer sie übernimmt, muss sie auf die eigenen Werte zurechtbiegen.

Beim Aufruf: den richtigen Agenten finden

Eine Sache, die mir am Anfang oft Ergebnisse beschert hat, die nicht zu meinen Erwartungen passten: Beide Tools haben unterschiedliche Mechanismen, den richtigen Agenten zu aktivieren – und beide funktionieren nur, wenn man weiß, wie.

Claude Code: explizit benennen

Claude Code wählt nicht immer selbstständig den passenden Sub-Agenten aus – zumindest nicht zuverlässig.

Die Lösung ist simpel: Ich nenne den Agenten explizit im Prompt. Statt „Erstelle einen Use Case für die Suchfunktion" schreibe ich „Nutze den Business Analysten und erstelle einen Use Case für die Suchfunktion." Seit ich das konsequent mache, läuft der richtige Agent. Nicht manchmal – immer.

Das klingt nach einer Kleinigkeit. Aber es ist der Unterschied zwischen einem Workflow, der verlässlich funktioniert, und einem, bei dem man nie ganz sicher ist, welche Rolle der Agent gerade einnimmt.

Anthropic beschreibt das Konzept der Sub-Agenten und den offiziellen Einführungsrahmen in ihrer Introduction to Sub-agents: Die Idee ist genau diese Isolation – separate Kontextfenster, fokussierte Aufgaben, keine Vermischung von Rollen. Was dort nicht steht: dass man im Prompt aktiv auf diese Isolation hinweisen muss, damit sie auch greift.

GitHub Copilot: Agent-Picker im Chat-Fenster

Bei GitHub Copilot reicht es nicht, den Agenten im Prompt zu benennen – man muss ihn aktiv im Chat-Fenster auswählen. Oben im Copilot-Chat-Fenster befindet sich ein Selektor, über den man zwischen den verfügbaren Agenten wechseln kann. Erst wenn der richtige Agent dort ausgewählt ist, arbeitet Copilot in dessen Rolle.

Das ist ein anderes Interaktionsmuster als bei Claude Code. Bei Claude Code ist der Prompt die Schnittstelle – der Agent wird durch Sprache aktiviert. Bei Copilot ist es die UI. Beides hat seine Logik: Claude Code ist ein CLI-Tool, Copilot ist tief in VSCode integriert. Jedes Tool nutzt den Kanal, der in seiner Umgebung natürlich ist.

Wer das vergisst und einen Prompt ohne Agenten-Auswahl absetzt, arbeitet mit dem Default-Copilot – und wundert sich, warum der Stil, der Kontext und der Output nicht passen. Das ist mir oft genug passiert, bevor ich es mir angewöhnt habe, zuerst den Agenten auszuwählen und dann erst die Aufgabe zu beschreiben.

Mein Setup: zwei Tools, ein Workflow

Beide Tools funktionieren – aber auf unterschiedliche Arten, mit unterschiedlichen Schwerpunkten.

Claude Code setzt auf Datei-basierte Agenten in .claude/agents/, die über den Prompt gesteuert werden. Der Workflow ist terminal-nah: Ich tippe, der richtige Agent antwortet, das Ergebnis landet als Datei im Projekt. Die Integration in die eigene Projektstruktur ist friktionslos, weil die Dateien direkt im Repository liegen und versioniert werden. Wer an meinem Projekt arbeitet, hat sofort alle Agenten zur Hand.

GitHub Copilot setzt auf UI-Integration: Der Agenten-Picker ist visuell, der Workflow läuft in VSCode, die Ergebnisse erscheinen direkt im Kontext der aktuellen Datei. Für den Moment der Implementierung, wenn ich Code schreibe und unmittelbares Feedback brauche, fühlt sich das natürlicher an.

Mein praktisches Setup ist deshalb kein Entweder-oder, sondern eine Arbeitsteilung. Die Planungsphase – Business Analyst, Solution Architect, Realisierungsplan – läuft über Claude Code im Terminal. Der Developer-Agent, der im Kontext der aktiven Dateien und der IDE arbeitet, läuft über Copilot. Für jeden Kontext ist das jeweilige Tool der natürlichere Kanal – und das spiegelt sich in den Agenten wider, die ich für jedes Tool anlege.

Optional: Agenten mit Skills erweitern

Was ich in diesem Post beschrieben habe, dreht sich um das Anlegen der Agenten selbst – die Rolle, der Kontext, die Handoffs, die Grenzen. Es gibt aber noch eine zweite Ebene, die ich hier bewusst getrennt halte, weil sie auf den fertigen Agenten aufsetzt: Skills.

Anthropic beschreibt das Konzept in ihrem Artikel Equipping agents with Agent Skills: spezialisierte Fähigkeiten, die in wiederverwendbare Dateien verpackt werden – ein abgegrenztes Stück Anleitung, das ein Agent bei Bedarf heranzieht, statt es dauerhaft in seiner Rollenbeschreibung mitzuschleppen. Wo der Agent das Wer und das Wofür definiert, liefert ein Skill das konkrete Wie für eine wiederkehrende Aufgabe.

Für die vier Agenten aus dieser Serie heißt das: Man muss nicht alles in die Agenten-Datei pressen. Wiederkehrendes Spezialwissen – etwa eine feste Anleitung, wie ein Sequenzdiagramm aufgebaut sein soll, wie ein bestimmter Migrationsschritt abläuft oder welches Format eine Commit-Message haben muss – kann man als eigenständigen Skill auslagern und mehreren Agenten zur Verfügung stellen. Der Agent bleibt schlank, der Skill ist wiederverwendbar, und beides lässt sich unabhängig voneinander pflegen.

Ich behandle das als optionalen zweiten Schritt. Erst steht der Agent mit seinen drei Bereichen – Kontext, Handoffs, Grenzen. Wenn ich dann merke, dass sich ein bestimmtes Wissen über mehrere Agenten hinweg wiederholt oder die Rollenbeschreibung zu überladen wird, wandert es in einen Skill. Das Prinzip gilt für die Claude-Code-Seite genauso wie für den GitHub-Copilot-Agenten – und für das Zusammenspiel beider.

Fazit

Agenten anlegen ist kein einmaliger Aufwand, der danach für immer läuft. Es ist ein iterativer Prozess: einen Ausgangspunkt wählen – Template oder Scaffold – für das Projekt anpassen, im Einsatz beobachten, nachschärfen.

Wer schnell starten will und eine der vier Rollen aus dieser Serie braucht, findet die Templates auf GitHub. Wer eine eigene Rolle entwerfen will, kommt mit /agents in Claude Code oder /create-agent in Copilot ebenfalls schnell zu einer Grundstruktur. Wer beide Tools nutzt, kann sich das Hin-und-Her sparen, indem er ein Claude-Template per Copilot mit GPT-5.5 oder älter in eine Copilot-konforme Variante übersetzen lässt.

Was keiner dieser Wege ersetzt, ist der Teil danach: die Anpassung an die eigene Codebase, die expliziten Handoffs zwischen den Agenten, die klar gezogenen Grenzen. Genau der Teil, der den Agenten wirklich nützlich macht – und genau der Teil, den kein Tool und kein Template einem abnehmen kann. Den muss man selbst einbringen. Aber er ist überschaubar: zehn bis zwanzig Minuten pro Template, eine halbe Stunde für einen scaffoldeten Agenten. Eine Investition, die sich nach dem zweiten oder dritten Einsatz bezahlt macht – weil der Agent dann liefert, was ich erwarte, ohne dass ich es jedes Mal neu erklären muss.