GitHub-Copilot-Prompts: Kommentare, Kontext und Chat

Ein Entwickler schreibt // berechne die Summe über eine leere Funktion. Copilot schlägt zehn Zeilen vor, die die Preise addieren, ohne MwSt., ohne Treuerabatt, mit Fließkommazahlen, wo das Projekt ganze Cent-Beträge verwendet. Der Code kompiliert und ist falsch, weil der Kommentar die einzige gegebene Information war.

GitHub Copilot steuerst du auf drei Wegen: durch das, was du in die Datei schreibst, durch das, was du im Chat verlangst, und durch die Regeln, die du für das ganze Repository festlegst. Jeder hat seine eigenen Reflexe.

Die Inline-Vorschläge: Der Kommentar ist dein Prompt

Wenn Copilot deinen Code beim Tippen vervollständigt, stützt es sich auf das, was den Cursor umgibt: den Funktionsnamen, die geöffneten Dateien, die Kommentare. Ein aussagekräftiger Name und ein Kommentar, der das Verhalten beschreibt, sind mehr wert als eine lange Einleitung.

Vergleiche diese beiden Funktionsanfänge.

// berechne die Summe
function summe(positionen) {

// Summe eines Warenkorbs in Cent (ganze Zahlen).
// Wendet den Treuerabatt von 5 % an, wenn kunde.istStammkunde wahr ist,
// und addiert dann die MwSt. von 20 %. Abgerundet auf den Cent.
// Leerer Warenkorb: gibt 0 zurück.
function warenkorbSumme(positionen, kunde) {

Der zweite nennt die Einheit, die Reihenfolge der Operationen, die Rundung und den Grenzfall. Copilot muss nichts mehr raten. Wenn du dir bei der Geschäftsregel nicht sicher bist, verlange nicht vom Code, sie an deiner Stelle zu erraten: Schreib sie zuerst auf.

Zwei Gewohnheiten helfen ebenfalls. Lass die Dateien geöffnet, die zeigen, wie das Projekt die Dinge angeht (ein benachbartes Modul, ein bestehender Test), denn sie dienen als Beispiele. Und lies jeden Vorschlag, bevor du ihn annimmst, vor allem die längeren: zehn Zeilen, die du nicht gelesen hast, auf einmal zu akzeptieren heißt, Code zu schreiben, den niemand versteht.

Der Chat: Wähle, was er sieht

Im Chat hängt die Qualität der Antwort davon ab, was Copilot vor Augen hat. Je nach Editor kann es die geöffnete Datei sehen, den Code, den du markiert hast, und die Dateien, die du ausdrücklich zum Kontext hinzufügst (in Visual Studio Code zum Beispiel, indem du sie mit # benennst). Sieh nach, was deine Oberfläche anbietet, denn die Optionen ändern sich von Editor zu Editor.

Der nützliche Reflex ist, den betroffenen Code zu markieren, bevor du deine Frage stellst. Ein Beispiel für eine Anfrage zur Fehlerbehebung:

Die markierte Funktion liefert 0 für einen Warenkorb mit zwei Artikeln, wenn der Kunde Stammkunde ist. Ohne Rabatt gibt sie die richtige Summe aus.

Suche die Ursache, erkläre sie in zwei Sätzen und schlage dann die kleinstmögliche Korrektur vor. Schreibe den Rest der Funktion nicht um und ändere ihre Signatur nicht.

„Die kleinstmögliche“ schützt deine Commit-Historie. Ohne diese Grenze ordnet das Tool gern die ganze Datei um, und das Code-Review wird zum Albtraum.

Für gängige Aufgaben gibt es im Chat mehrerer Editoren Befehle wie /explain, /fix oder /tests. Sie ersparen dir, dieselbe Anfrage neu zu schreiben, aber ergänze sie um einen Satz mit Vorgaben. Zum Beispiel nach /tests:

Schreibe die Tests der markierten Funktion mit dem Framework, das im Ordner tests/ bereits verwendet wird. Decke ab: leerer Warenkorb, Stammkunde, ein Preis von null, eine Rundung, die zwischen zwei Cent fällt. Ein Test pro Fall, mit einem Namen, der den Fall beschreibt.

Starte danach die Tests. Ein Test, den Copilot geschrieben hat, kann bestehen, weil er prüft, was der Code tut, und nicht, was er tun sollte. Lies die erwarteten Werte einzeln nach.

Die Projektregeln: eine Anweisungsdatei

Du hast es satt, „wir verwenden ganze Cent-Beträge“ und „keine neue Abhängigkeit, ohne darüber zu sprechen“ zu wiederholen? GitHub erlaubt es, im Repository eine Datei .github/copilot-instructions.md abzulegen, in Markdown und natürlicher Sprache geschrieben. Copilot liest sie bei Anfragen zu diesem Repository. Die Unterstützung variiert je nach Editor und Funktion, schau also für deinen Fall in die Dokumentation von GitHub.

# Projektregeln

- Beträge sind ganze Zahlen in Cent. Niemals Fließkommazahlen für Geld.
- Tests mit Vitest, im Ordner tests/, eine Datei pro Modul.
- Füge keine Abhängigkeit hinzu, ohne mich in der Antwort darauf hinzuweisen.
- Fehlermeldungen für Nutzer sind auf Deutsch, Namen im Code auf Englisch.

Halte diese Datei kurz und überprüfbar. Zehn präzise Regeln sind mehr wert als drei Seiten Grundsätze, und eine Regel, die du nie nachliest, widerspricht irgendwann dem Code. Dasselbe gilt für die Systemanweisungen und die Anweisungen für Agenten: Schreib auf, was ein neuer Kollege am ersten Tag wissen sollte.

Was Copilot nicht weiß

Es kennt weder deine Architekturentscheidungen noch deine Fehlerhistorie noch die Regeln, die im Kopf des Teams stecken. Es kann außerdem eine Funktion einer Bibliothek vorschlagen, die es nicht gibt, oder eine Syntax einer älteren Version. Verwendet ein Vorschlag einen Aufruf, den du nicht kennst, öffne die Dokumentation der Bibliothek, bevor du weitermachst.

Denk auch an den Inhalt deines Codes: Zugangsschlüssel, Passwörter, Kundendaten. Setze sie weder in einen Kommentar noch in den Chat, und lies die Bedingungen deines Tarifs und die Regeln deines Arbeitgebers zum Senden von Code an einen externen Dienst. Die Grundlagen von Review und Debugging mit einer KI stehen in unserem Artikel über Prompts für Entwickler.

Heute ausprobieren

Nimm die nächste Funktion, die du schreiben willst. Schreib, bevor du die erste Zeile tippst, ihr vollständiges Verhalten als Kommentar auf: Eingaben, Ausgaben, einen Grenzfall. Sieh dir an, was Copilot vorschlägt, und korrigiere dann den Kommentar, nicht den Code, wenn der Vorschlag von dem abweicht, was du wolltest.