Copilot Agent Mode – Konfiguration und Best Practices
Im sogenannten Agent Loop, dem Thema des vorliegenden Beitrags, überprüft der Copilot dabei selbstständig mithilfe von Tools, ob das gewünschte Ziel erreicht wurde. Ist dies nicht der Fall, optimiert er seine Schritte so lange, bis das Ergebnis passt.
Einfach nur einen Prompt einzugeben, führt jedoch selten sofort zu einem brauchbaren Resultat – außer vielleicht bei sehr einfachen „Hello World“-Beispielen. „Out of the box“ verfügt der Copilot nur über einen begrenzten Kontext: Er kennt die geöffneten Dateien, kann lesen und schreiben und über seine Tools auch Build- und Testprozesse anstoßen. Doch wie sieht es mit firmenspezifischen Entwicklungsrichtlinien, Architekturvorgaben oder Coding-Standards aus?
Um das volle Potenzial des Agent Mode auszuschöpfen, müssen wir ihm einen optimalen Arbeitskontext geben. Das geschieht über gezielte Konfigurationen, die dem Agenten alles bereitstellen, was er für qualitativ hochwertige Ergebnisse benötigt. Den Delimarsky hat dieses Problem in einem Blogpost treffend beschrieben: „The issue isn’t the coding agent’s coding ability, but our approach. We treat coding agents like search engines when we should be treating them more like literal-minded pair programmers. They excel at pattern recognition but still need unambiguous instructions.“
Mit anderen Worten: Ob wir den Agent Mode erfolgreich nutzen können, liegt weniger an der Fähigkeit der KI, sondern an unserer Art, sie optimal einzusetzen. Ohne präzise Anweisungen – sei es über gute Prompts, Custom Instructions oder den Einsatz von Tools und MCPs – muss die KI raten und bewegt sich womöglich in die falsche Richtung.
Agent Mode – Prompts, Instructions und Tools
Bevor wir uns an die Konfiguration wagen, sollten wir verstehen, wie der Agent Mode funktioniert. In VS Code (und anderen IDEs) steht Copilot in drei Modi zur Verfügung: Ask, Edit und Agent. Im Agent Mode formulieren wir über einen Prompt ein klares Ziel. Copilot plant anschließend eigenständig die Umsetzung und führt mehrere Schritte aus, bis er die Zielerreichung positiv bewertet. Dieser Prozess kann das Lesen und Schreiben von Dateien, das Ausführen von Build- oder Test-Tools sowie andere kommandogesteuerte Aktionen umfassen.
Die Entscheidungsfindung des Agenten basiert auf mehreren Bausteinen:
- Prompt: Die zentrale Anweisung, die das Ziel beschreibt.
- Kontext aus dem Projekt: Copilot nutzt lokalen oder serverseitigen Code Index (zum Beispiel GitHub oder Azure DevOps), um relevante Dateien in den Kontext einzubinden. Geöffnete Dateien haben dabei höhere Priorität. Zusätzlich können wir dem Prompt explizite Datei- oder Verzeichnisreferenzen mitgeben (mittels #-Syntax).
- Custom Instructions: Projektspezifische Richtlinien wie Coding Guidelines oder Architekturspezifikationen werden als Custom Instructions hinterlegt, damit Copilot sie bei der Planung berücksichtigt.
- Tools und Commands: Über konfigurierbare Tools kann der Agent Kompilierungen starten, Tests ausführen oder externe Dokumentationen abfragen.
Mit dieser Kombination geben wir der KI die nötige Orientierung, um konsistent Code auf dem Niveau eines erfahrenen Teammitglieds zu erzeugen.
Die entsprechenden Konfigurationen werden im Repository in einer klar definierten Struktur abgelegt. Alles, was den Prompt erweitert oder vorgibt, liegt als Markdown-Datei vor. Diese Dateien enthalten Fließtext, können aber über Frontmatter-Blöcke strukturierte Metadaten (YAML) bereitstellen. Dadurch weiß der Agent, welche Dateien und Regeln für eine bestimmte Aufgabe relevant sind.
Die Integration von MCPs erfolgt über JSON-Dateien. Sie können entweder Repository-weit oder benutzerspezifisch definiert werden – eine zentrale Ablage im Repo hat jedoch den Vorteil, dass alle Teammitglieder dieselbe Konfiguration nutzen. Änderungen können dann wie gewohnt über Pull Requests geprüft und freigegeben werden. Bild 1 zeigt die vorgegebene Verzeichnisstruktur für diese Konfigurationen.
Verzeichnisstruktur für Konfigurationen und Anpassungen (Bild 1)
AutorIn den nächsten Abschnitten gehen wir Schritt für Schritt auf die einzelnen Bereiche ein.
Custom Instructions: Die KI mit eigenen Regeln steuern
Der einfachste Weg, den Copilot-Agenten auf die eigenen Bedürfnisse abzustimmen, ist das Bereitstellen von Custom Instructions. Im Kern handelt es sich dabei um einen System Prompt, der jedem vom Benutzer eingegebenen Prompt vorangestellt wird. Die Instruktionen werden als Markdown-Datei hinterlegt und dienen als eine Art „Mini-Wiki“ für die KI: Wir definieren hier Coding-Standards, Best Practices und projektspezifische Richtlinien.
Der einfachste Ansatz ist eine einzelne Datei unter .github/copilot-instructions.md. Ist sie vorhanden, stellt Copilot deren Inhalt jedem Prompt automatisch voran. Damit stehen die allgemeingültigen Instruktionen bei jeder Aufgabe zur Verfügung. Aktiviert wird dieses Verhalten über die Einstellung github.copilot.chat.codeGeneration.useInstructionFile.
Listing 1 zeigt ein minimales Beispiel für eine solche Datei.
Listing 1: .github/copilot-instructions.md
# .NET Project Guidelines
- Use **async/await** for all I/O-bound operations in ASP.NET Core.
- Follow our naming conventions (PascalCase for class and method names, camelCase for locals).
- All new APIs **must include XML documentation comments**.
- Use dependency injection for services rather than static instances.
- Prefer **minimal APIs** for simple HTTP endpoints instead of MVC controllers. Mit einem solchen Regelwerk weiß Copilot, welche Patterns und Konventionen er beim Generieren von Code berücksichtigen soll. Im Beispiel würde er beim Erstellen eines neuen Endpunkts automatisch die Minimal-API-Variante bevorzugen.
Da die Instructions jedem Prompt vorangestellt werden, sollten sie möglichst präzise formuliert sein. Unklare oder überlange Instruktionen können die Qualität der Ergebnisse und die Performance negativ beeinflussen.
In komplexeren Projekten kommen oft unterschiedliche Technologien zum Einsatz – beispielsweise C# im Backend und TypeScript im Frontend. Es wäre wenig sinnvoll, eine TypeScript-Anweisung bei der Generierung von C#-Code einzubinden. Deshalb empfiehlt sich der Einsatz von Scoped Instructions.
Scoped Instructions werden im Verzeichnis .github/instructions/ abgelegt. Die Dateien müssen auf *.instructions.md enden und enthalten einen Frontmatter-Block mit Metadaten. Über den applyTo-Filter wird festgelegt, dass die Instruktionen nur dann eingefügt werden, wenn sie für die jeweilige Datei oder den Dateipfad relevant sind. Das Ergebnis: feingranulare Kontrolle bei minimalem Prompt-Overhead. Listing 2 und Listing 3 zeigen je ein Beispiel für eine Scoped Instruction.
Listing 2: .github/instructions/csharp.instructions.md
---
applyTo: "**/*.cs"
description: Guidelines for C# code (ASP.NET Core backend)
---
# Backend Coding Standards (C#)
- Use `string.IsNullOrEmpty` or `IsNullOrWhiteSpace` for null/empty checks instead of length comparisons.
- Exception messages should be localized when thrown.
- Logging: Use `ILogger` with appropriate log levels; no console writes.
- Authentication: Use ASP.NET Identity for user management, do not implement custom crypto. Listing 3: github/instructions/typescript.instructions.md
---
applyTo: "**/*.{js,jsx,ts,tsx}"
description: Guidelines for web client code (React frontend)
---
# Frontend Coding Standards (TypeScript/React)
- Always use functional React components and React Hooks.
- Use TypeScript strict mode and define interfaces for component props and state.
- Follow our ESLint rules; code should pass linting without warnings.
- Use our custom `fetchClient` wrapper instead of direct `fetch` calls for API requests. Best Practices für Custom Instructions
Custom Instructions sollten wie ein kompakter Stil-Leitfaden wirken. Diese Grundsätze haben sich bewährt:
- Prägnanz geht vor Länge: Formuliere die Instruktionen klar und knapp.
- Always/Never-Regeln: Fokussiere dich auf Vorgaben, die auch ein erfahrener Kollege hilfreich fände (zum Beispiel „API-Resultate immer paginieren“ oder „Secrets niemals in Konfigurationsdateien speichern“).
- Struktur nutzen: Überschriften, Listen und Codeblöcke machen die Anweisungen nicht nur für Copilot, sondern auch für Entwickler:innen leichter verständlich.
- Relevanz beachten: Da die Instruktionen Teil eines jeden Prompts werden, sollten sie nicht unnötig aufgebläht sein.
- Pflege als „lebendes Dokument“: Aktualisiere die Instruktionen regelmäßig, genau wie eine README oder Architektur-Dokumentation.
Die obigen Listings sind im Sinne der Übersichtlichkeit und Veranschaulichung bewusst kurz gehalten. Für eine umfassendere Sammlung empfiehlt sich ein Blick in das GitHub-Repository github/awesome-copilot. Dort findet sich eine kuratierte Auswahl von Instructions, Prompts und Chat Modes. Mittlerweile gibt es sogar einen MCP-Server, der das Suchen und Einbinden solcher Ressourcen ins eigene Repository erleichtert.
Prompt Files – Wiederverwendbare Tasks Templates für den Agent
Natürlich kann man jederzeit einen neuen Prompt direkt ins Chatfenster eingeben. In der täglichen Arbeit von Entwickler:innen wiederholen sich jedoch viele Aufgaben – und genau hier spielen Prompt Files ihre Stärke aus. Sie ermöglichen es, wiederkehrende Aufgaben als Vorlagen zu speichern und bei Bedarf schnell abzurufen.
Prompt Files werden im Verzeichnis .github/prompts/ abgelegt. Ihre Dateinamen müssen auf *.prompt.md enden. Auch hier lassen sich über den Frontmatter-Block Metadaten wie der Modus (mode), das zu verwendende Modell (model) und die benötigten Tools definieren.
Listing 4 zeigt ein Beispiel für ein Security-Review-Prompt, das den Modus ask nutzt. Dieser Modus liefert nur eine Antwort, ohne Dateien zu editieren. Außerdem wird explizit das Modell GPT-5 gesetzt, sodass eine konsistente Qualität der Analyse sichergestellt ist – unabhängig von dem vom Nutzer ausgewählten Default-Modell. Als Tools werden codebase und search aktiviert, damit Copilot den Code lesen und durchsuchen kann.
Listing 4: .github/prompts/security-review.prompt.md
---
mode: ask
model: "GPT-5" # or Claude, etc., depending on availability
description: "Perform a security review of a REST API"
tools: ['codebase', 'search']
---
Perform a thorough **security audit** of the API routes in the current project. Check for:
- Proper authentication and authorization on each endpoint.
- Input validation and output encoding to prevent injection attacks.
- Usage of HTTPS and secure transport for sensitive data.
- Rate limiting and throttling to mitigate brute-force attacks.
- Error handling that avoids leaking stack traces or sensitive info.
**Output:** Provide a Markdown report listing any security issues found, grouped by severity, with recommended fixes for each. Prompt Files können dynamische Platzhalter enthalten, etwa ${selection} oder ${selectedText}, um den aktuell markierten Code aus dem Editor einzufügen. Auf diese Weise lassen sich etwa Prompt-Templates erstellen, die automatisch Unit-Tests für den ausgewählten Code generieren.
Neben Text-Selektionen gibt es Variablen für den aktuellen Dateinamen oder das Arbeitsverzeichnis. Darüber hinaus lassen sich eigene Eingabevariablen wie beispielsweise ${input:variableName} definieren, die beim Ausführen des Prompts über den Chat befüllt werden.
Hat man zum Beispiel eine Datei scaffold-controller.prompt.md, kann diese mit dem Slash-Befehl /scaffold-controller aufgerufen werden. Übergibt man zusätzliche Parameter wie /scaffold-controller: name=WeatherForecast, wird die Eingabevariable name mit dem Wert WeatherForecast gesetzt – ideal für Templates, die Codegerüste oder neue API-Endpunkte generieren.
Gut geschriebene Prompt Files funktionieren wie kleine AI-Skripte:
- Sie beschreiben klar und eindeutig, was Copilot tun soll und wie der Output aussehen muss.
- Besteht der Task aus mehreren Schritten, empfiehlt sich die Verwendung von nummerierten Listen oder Checklisten, um die Ausführung zu strukturieren.
- Markdown erlaubt Links auf andere Dateien, sodass sich Bausteine mehrfach verwenden lassen, ohne sie zu duplizieren.
- Prompt Files können sogar ineinander verschachtelt werden, wenn ein Prompt einen anderen aufruft.
Gerade für .NET-Entwickler:innen lohnt es sich, solche Vorlagen für häufige Aufgaben anzulegen – zum Beispiel für das Erstellen von CRUD-Methoden, das Generieren neuer Minimal-API-Routen oder das Hinzufügen von Unit-Tests. So entsteht mit der Zeit eine Bibliothek wiederverwendbarer Workflows, die Copilot in der täglichen Arbeit noch wertvoller macht.
Custom Chat Modes – spezifische Personas für den eigenen Workflow
Mit Custom Chat Modes gehen wir noch einen Schritt weiter: Wir können Copilot in verschiedene Rollen versetzen oder ihn für spezifische Workflows vorkonfigurieren. Während die Standardmodi Ask, Edit und Agent in VS Code bereits mächtig sind, erlauben Custom Chat Modes eine feinere Anpassung an den jeweiligen Entwicklungsprozess.Dazu legen wir eine Datei mit dem Namensschema *.chatmode.md im Verzeichnis .github/chatmodes/ an. Der Aufbau entspricht dem der Prompt Files: Im Frontmatter-Block definieren wir Metadaten wie Beschreibung, verwendetes Modell und freigegebene Tools. Der eigentliche Inhalt der Datei beschreibt die Persona oder den Modus in natürlicher Sprache. Listing 5 zeigt ein einfaches Beispiel für einen eigenen „Planning-Modus“.
Listing 5: .github/chatmodes/planning.chatmode.md
---
description: Generate an implementation plan for new features or refactoring tasks.
tools: ['codebase', 'search', 'usages'] # read-only tools to gather info
model: GPT-5
---
# Planning Mode Instructions
You are in **Planning Mode**. Your goal is to help plan a new feature or a major refactoring without writing any code yourself.
1. **Do NOT make code edits** – do not modify files or provide code implementations.
2. Analyze the project and user requirements, and produce a **step-by-step technical plan** for implementation.
3. Consider architecture, data models, and impacts on existing systems. Ensure the plan addresses potential edge cases and testing strategy.
Format the output as a markdown document with sections for Overview, Requirements, Implementation Steps, and Testing. Sobald eine solche Datei im Repository liegt, erscheint der neue Chat Mode im Modus-Dropdown von Copilot Chat und kann direkt ausgewählt werden. Damit entsteht eine eigene „Persona“, die exakt auf die jeweilige Aufgabe zugeschnitten ist.
Nutzen von Custom Chat Modes
Custom Chat Modes befinden sich aktuell noch in der Preview-Phase und richten sich eher an fortgeschrittene Teams, die ihre KI-gestützten Workflows optimieren wollen. Die Standardmodi decken bereits viele Szenarien ab, doch mit eigenen Chat Modes lassen sich projektspezifische Prozesse abbilden, die sonst nur manuell oder mit zusätzlichen Prompts umgesetzt werden müssten.
Gerade aus der Perspektive von .NET-Entwickler:innen sind einige spannende Anwendungsfälle denkbar:
- Code-Review-Assistenz: Ein Chat Mode, der sich wie ein erfahrener Reviewer verhält, Diffs analysiert und gezielt auf mögliche Bugs, Sicherheitsprobleme oder Verbesserungen hinweist.
- Architekturberatung: Ein Modus, der Architekturrichtlinien prüft, bestehende Strukturen analysiert und Vorschläge zur Konsistenz und Skalierbarkeit macht.
- Refactoring-Coach: Eine Persona, die Vorschläge für schrittweises Refactoring macht, ohne selbst Änderungen vorzunehmen.
Mit solchen spezialisierten Chat Modes lässt sich der Agent Mode noch gezielter in den Entwicklungsprozess integrieren – und Copilot wird zu einem echten virtuellen Teammitglied, das die Arbeitsschritte der Entwickler:innen unterstützt, ohne deren Verantwortung zu übernehmen.
Spec-Driven Development mit GitHub Spec Kit
Selbst mit Custom Instructions, Prompt-Vorlagen und integrierten Tools kann die Arbeit mit einem KI-Coding-Assistenten manchmal unstrukturiert wirken: Man formuliert eine Anforderung, erhält Code – doch entspricht er wirklich exakt der gewünschten Funktionalität? Genau hier setzt Spec-Driven Development an.
Das Spec Kit von GitHub ist kein Copilot-Feature, sondern ein Open-Source-Toolkit (plus Methodik), das sich nahtlos mit dem Copilot Agent Mode kombinieren lässt. Ziel ist es, den Entwicklungsprozess klarer zu strukturieren: Anstatt sofort Code zu generieren, beginnen wir mit einer Spezifikation, die als genauso wichtig behandelt wird wie der Code selbst.
Das Spec Kit ist auf GitHub verfügbar (github/spec-kit) und besteht aus Prompt Files sowie einfachen Bash-Skripten. Diese interagieren mit dem Agent Mode und sorgen dafür, dass aus einer groben Feature-Idee zunächst eine detaillierte Spezifikation entsteht, die dann in einen Plan und schließlich in konkrete, umsetzbare Aufgaben zerlegt wird.
Der Workflow von Spec Kit gliedert sich in vier klar definierte Phasen:
- Specify – Spezifikation erstellenZu Beginn beschreiben wir das gewünschte Feature oder die geplante Änderung auf hohem Abstraktionsniveau. Hier geht es um das „Was“ und „Warum“, jedoch nicht um das „Wie“. Typischerweise erfassen wir User Stories, Akzeptanzkriterien und gewünschte User Flows. Ein Beispiel wäre etwa /specify Add password reset functionality to the user account system.Der Copilot Agent Mode erstellt daraus eine erste Spezifikation als Markdown-Dokument mit User Flows, erwarteten Ergebnissen und Erfolgskriterien. Diese Spezifikation kann vor der nächsten Phase manuell überprüft und angepasst werden.
- Plan – technisches Design entwickelnIn der Planungsphase werden die technischen Details ergänzt. Mit dem Prompt /plan generiert Copilot einen Implementierungsplan, der Architekturentscheidungen, Bibliotheken und Frameworks, etwa Use ASP.NET Core Identity for password reset, berücksichtigt.
- Tasks – Arbeitspakete ableitenNachdem der Plan validiert wurde, erstellen wir mit dem Prompt /tasks eine Task-Liste. Jede Aufgabe ist klein genug, um vom Agent Mode einzeln umgesetzt zu werden.
- Implement – Umsetzung startenJetzt beginnt die eigentliche Implementierung. Wir referenzieren die zuvor erstellten Task-Dokumente und beauftragen Copilot, die einzelnen Aufgaben Schritt für Schritt abzuarbeiten.
In Bild 2 ist die Integration von Spec Kit in VS Code dargestellt: Nach der Installation enthält das Repository die Prompt-Dateien und Skripte, die während des Workflows genutzt werden. Das Verzeichnis specs/ wird automatisch mit den Spezifikations- und Task-Dateien gefüllt. VS Code zeigt diese Dokumente im Screenshot an, während im Copilot-Fenster die Abarbeitung der einzelnen Tasks verfolgt werden kann.
Durch diesen strukturierten Ansatz vermeiden wir unklare Anforderungen, verbessern die Nachvollziehbarkeit und schaffen eine klare Dokumentationsspur. Besonders in Teams sorgt Spec-Driven Development dafür, dass alle Beteiligten dieselbe Vorstellung vom Ziel haben, bevor der erste Code geschrieben wird.
Spec Kit im Einsatz mit GitHub Copilot (Bild 2)
AutorFazit – Copilot Agent Mode richtig einsetzen
Der Copilot Agent Mode ist ein mächtiges Werkzeug – besonders in komplexen Projekten. Sein volles Potenzial entfaltet er aber erst dann, wenn wir ihm einen klaren Rahmen geben: Custom Instructions, Prompt Files und spezielle Chat Modes sorgen dafür, dass die KI unsere Coding-Standards, Architekturprinzipien und Workflows versteht. Mit Spec-Driven Development und dem GitHub Spec Kit bringen wir zusätzliche Struktur ins Spiel und reduzieren Missverständnisse, bevor der erste Code geschrieben wird.
Wichtig ist, den Agent Mode bewusst und inkrementell einzusetzen: große Features in kleinere Schritte zerlegen, Ergebnisse prüfen und bei Bedarf nachsteuern. Mit jedem Zyklus lernen sowohl wir als auch Copilot dazu – und die Qualität der Ergebnisse steigt kontinuierlich.
Richtig konfiguriert wird Copilot vom reinen Codegenerator zum virtuellen Teammitglied, das Routinearbeit übernimmt, Best Practices durchsetzt und uns mehr Raum für Architektur und kreative Lösungen lässt.
