Bewährte Praktiken für GitHub-Copilot-Prompts

GitHub Copilot liefert nützlichere Hilfe beim Programmieren, wenn die Aufgabenbeschreibung Problem, Umfang, Einschränkungen und Erfolgsnachweis erklärt. Ein kurzer Prompt kann für eine lokale Codevervollständigung funktionieren. Eine Repository-Änderung braucht dieselbe Klarheit wie ein gut geschriebenes Issue.

Die Produktoberfläche spielt eine Rolle: Die aktuelle GitHub-Dokumentation beschreibt repositoryweite Anweisungen, pfadspezifische Anweisungen, Agent-Anweisungen und wiederverwendbare Prompt-Dateien, deren Unterstützung je nach Feature und IDE variiert. Nutze die Tools, die in deiner Umgebung verfügbar sind, aber halte die zugrunde liegende Anfrage explizit.

Gib der Codevervollständigung einen lokalen Vertrag

Für eine kleine Funktion reichen der umgebende Name, die Typen und Tests oft aus. Ergänze das Verhalten, das leicht subtil falsch umgesetzt werden kann:

Implementiere einen Parser für den retry-after-Header.

Gib Millisekunden entweder für Sekunden oder ein gültiges HTTP-Datum zurück. Gib null für
einen fehlenden, negativen oder ungültigen Wert zurück. Wirf keinen Fehler aus einem
Pfad zur Behandlung von Response-Fehlern.
Füge tabellengesteuerte Tests für Sekunden, ein zukünftiges Datum, ein vergangenes Datum
und fehlerhafte Eingaben hinzu.

Der Vertrag leitet die Vervollständigung an, ohne ein langes Architektur-Briefing zu verlangen.

Beschreibe Testarbeit als Verhalten

Vermeide:

Schreibe Tests für den Präferenzen-Hook.

Nutze:

Füge Tests für den Präferenzen-Hook mit den bestehenden Testkonventionen hinzu.

Prüfe, dass der anfängliche Ladezustand nicht umleitet, ein erfolgreicher Lesezugriff
die gespeicherten Präferenzen bereitstellt, eine Aktualisierung das vollständige
Präferenzobjekt atomar schreibt und eine fehlgeschlagene Aktualisierung den zuvor
sichtbaren Wert beibehält.

Verwende öffentliches Verhalten statt interner Funktionsaufrufzähler. Füge die
Regression hinzu, die beim gemeldeten Fehler fehlschlagen würde.

Der Assistent kennt jetzt einen nutzerseitigen Vertrag, einschließlich eines wichtigen Negativfalls.

Gib Refactoring-Prompts Regeln zur Verhaltenserhaltung

Codevorschläge können eine saubere lokale Abstraktion erzeugen und dabei ein öffentliches Detail verlieren. Nenne die Erhaltung in der Anfrage:

Extrahiere die wiederholte Statusdarstellung aus diesen zwei Karten.

Bewahre aktuelle Props, sichtbare Bezeichnungen, Namen von Analytics-Ereignissen,
Tastaturfokus und mobiles Layout. Begrenze Änderungen auf dieses Feature und seine
direkten Tests.

Liste vor der Bearbeitung das wiederholte Verhalten und die Unterschiede auf, die getrennt
bleiben müssen. Mache daraus keine gemeinsame Design-System-Komponente, außer das
vorhandene Primitive kann das Ergebnis nicht darstellen.

Wenn du das zu bewahrende Verhalten nicht benennen kannst, bitte Copilot zuerst, den aktuellen Vertrag und die Aufrufstellen zu erklären.

Debugge mit Symptomen und Belegen

Symptom: Die Suchseite zeigt veraltete Ergebnisse, nachdem ein Nutzer Filter geändert hat.

Erwartet: Die neueste Filterauswahl steuert die angezeigten Ergebnisse.
Beobachtet: Eine langsamere vorherige Anfrage kann eine neuere Antwort überschreiben.

Relevanter Code: die Filter-UI, der Request-Hook und der Ergebnis-Renderer. Kürzliche
Änderung: Request-Wiederholungen wurden hinzugefügt.

Skizziere zuerst den Lebenszyklus der Anfrage und konkurrierende Hypothesen. Nenne, welche
Logs oder welches Test-Timing jede Hypothese beweisen würden. Schlage dann die kleinste
Korrektur und Regressionstests vor. Ersetze die Datenschicht nicht ohne Belege.

So wird verhindert, dass eine allgemeine Antwort wie „Behebe die Race Condition“ zu einer unnötigen Migration der Zustandsverwaltung anwächst.

Nutze Repository-Anweisungen für stabilen Kontext

Stabile Regeln sollten, wo unterstützt, beim Projekt liegen:

wie Tests und Formatierung ausgeführt werden;
Einschränkungen bei der Bereitstellung;
unterstützte Locales oder Plattformen;
öffentliche APIs, die kompatibel bleiben müssen;
Pfade, bei denen Sicherheits- oder Barrierefreiheitsprüfungen wichtig sind.

Die GitHub-Dokumentation beschreibt benutzerdefinierte Anweisungen auf Repository-Ebene und gezieltere Anweisungsdateien. Halte diese Anweisungen kurz, korrekt und auf dauerhafte Konventionen beschränkt. Die Details des aktuellen Tickets – Symptome, Ergebnis und Akzeptanzkriterien – gehören in den Prompt selbst.

Bitte um Dokumentation, die im Code verankert ist

Aktualisiere nach der neuen Umgebungsprüfung den Leitfaden zur Fehlerbehebung bei der
Bereitstellung.

Prüfe jeden Befehl und jede Umgebungsvariable anhand des Repositorys. Erkläre das
Erfolgssignal, das häufige Fehlersignal und die sichere nächste Aktion. Halte Geheimnisse
aus Beispielen heraus. Verlinke auf das bestehende Betriebshandbuch, statt es zu duplizieren.

Die Formulierung „anhand des Repositorys prüfen“ ist wichtig. Sie sagt Copilot, dass genaue Dokumentation eine Aufgabe zum Lesen von Code ist, nicht eine Aufgabe zur Texterzeugung.

Beende jeden wichtigen Prompt mit Akzeptanzkriterien

Nutze eine Ziellinie, die jemand anderes prüfen kann:

Fertig bedeutet:
- das gemeldete Nutzerverhalten ändert sich wie beschrieben;
- geschütztes Verhalten bleibt unverändert;
- fokussierte Tests beweisen den neuen und den alten Pfad;
- die Typprüfung und der relevante Lint-Befehl bestehen;
- der Diff enthält keine nicht zusammenhängende Bereinigung.

Für die allgemeine Prompt-Struktur lies wie man bessere KI-Prompts schreibt. Für aufgabenspezifische Muster fahre mit Prompt Engineering für Entwickler fort und vermeide dann die Fehlermodi in Fehlern von KI-Coding-Assistenten und wie du sie vermeidest.

Wenn eine Programmieraufgabe Skripte, Befehlsausgabe oder eine Terminal-Reproduktion umfasst, validiere sie, statt sie aus dem Gedächtnis zu beschreiben. Übe den Kommandozeilen-Workflow in deinem Browser, bevor du ihn in einen Prompt oder Test verwandelst.