So gibst du einem KI-Coding-Agenten zuverlässiges Domänenwissen

Ein allgemeiner Coding-Agent kann eine plausible Antwort schreiben und trotzdem das entscheidende Detail deines Stacks übersehen: eine kürzlich geänderte API, eine Repository-Grenze oder eine Konvention, die Produktion stabil hält. Die Lösung ist nicht immer ein längerer Prompt. Besser sind kleine, wiederverwendbare Domänenhinweise und eine überprüfbare Definition of Done.

1. Projektregeln und Domänenverfahren trennen

Beginne mit zwei Ebenen. Die erste ist ein kurzer Repository-Vertrag: Was ist das Projekt, wie ist es aufgebaut, welche Befehle bauen und testen es, welche Dateien sind tabu und was bedeutet fertig? Die JetBrains-Dokumentation zum Agentenverhalten beschreibt Dateien wie AGENTS.md und CLAUDE.md als Anweisungen, die mit dem Repository reisen und toolübergreifend gelten können.

Halte diese Ebene stabil und praktisch. Sie sollte Fragen beantworten, die jeder Agent bei jeder Aufgabe braucht: Wo liegt die Domänenlogik? Wie starte ich die Checks? Was darf ich nicht ändern? Regeln für nur einen Ablauf gehören in einen eigenen Skill.

Die zweite Ebene ist Domänenwissen: ein fokussiertes Rezept für eine wiederkehrende Aufgabe, etwa eine Android-Navigationsmigration, eine Datenbankschemaänderung oder eine Release-Checkliste. Ein Skill braucht einen klaren Auslöser, wenige Schritte und explizite Validierung. So bleibt der Standardkontext klein.

2. Einen Skill um eine Wissenslücke bauen

Ein guter Skill existiert, weil das Modell etwas wiederholt falsch macht oder immer wieder dasselbe herausfinden muss. Die Android-Skills-Philosophie schlägt einen nützlichen Test vor: Offizielle Skills adressieren überprüfbare Lücken, besonders bei sich ändernden APIs oder eigener Architektur. Sie warnt außerdem vor großen, ungeprüften Skill-Sammlungen mit möglicherweise schädlichen Anweisungen.

Ein kleiner Projekt-Skill kann so aussehen:

---
name: navigation-upgrade
description: Use when changing the app's Navigation 3 setup or upgrading its related APIs.
---

Before editing:
1. Inspect the current dependency versions and existing navigation tests.
2. Read the project's navigation conventions.
3. Confirm the target API in the approved platform documentation.

While editing:
- Make the smallest vertical change that satisfies the requested behavior.
- Do not replace the navigation architecture without approval.
- Preserve existing deep-link and back-stack behavior unless the task says otherwise.

Done means:
- The focused tests pass.
- The relevant build or lint command passes.
- The response names changed files, checks run, and unresolved risks.

Das Beispiel ist absichtlich eng. Es kopiert kein komplettes Framework-Handbuch in jeden Prompt, sondern sagt, wann das Verfahren gilt, was zu prüfen ist, welche Grenzen zählen und wie die Fertigstellung belegt wird. Ersetze die plattformspezifischen Checks durch echte Befehle und Konventionen deines Repositories.

3. Erst prüfen, dann handeln

Coding-Agenten verbinden eine Anfrage mit Umgebungskontext, schlussfolgern daraus und führen Aktionen wie Änderungen, Tests und Builds aus. Dieses Muster beschreibt AWS Prescriptive Guidance. Deine Anweisungen sollten die Phasen sichtbar machen.

Eine praktische Anfrage hat vier Teile:

1. Kontext: Feature, relevante Verzeichnisse und Einschränkungen nennen.
2. Plan: Dateien und Checks vor der Änderung auflisten lassen.
3. Änderung: Die kleinste Implementierung für die Akzeptanzkriterien verlangen.
4. Beleg: Tests, Lint, Build oder manuelle Prüfungen als Nachweis fordern.

So beginnt der Agent nicht blind mit der Implementierung und kompensiert später mit einem breiten Rewrite. Prüfung ist keine Zeremonie, sondern die Quelle des Kontextes, auf dem seine Entscheidungen beruhen.

4. Eine enge Feedbackschleife geben

Domänenhinweise erklären das Projekt; ausführbare Checks zeigen, ob die Änderung funktioniert. Der aktuelle TDD-Leitfaden von VS Code trennt eine rote Phase mit einem fehlschlagenden Test, eine grüne Phase mit minimaler Implementierung und eine Refactor-Phase bei weiterhin grünen Tests.

Du brauchst dafür keine drei komplizierten Agenten. Bitte bei einer kleinen Aufgabe zuerst um einen fehlschlagenden oder charakterisierenden Test. Implementiere erst danach. Schließe mit einem fokussierten Testlauf und den normalen Qualitäts-Gates ab. Ein nicht bestandener Check ist Information über Anforderung oder Umgebung, kein Grund, den Fehler in einer selbstsicheren Zusammenfassung zu verstecken.

5. Anleitung prüfen und ausmustern

Behandle einen Skill als versionierte Engineering-Infrastruktur. Überarbeite ihn bei Framework-Änderungen, wiederholten Agentenfehlern oder verrauschten Checks. Die Android-Skills-Anleitung beschreibt Skills ausdrücklich als Kandidaten für eine Ausmusterung: Modelle verbessern sich, während neue APIs neue Lücken erzeugen.

Eine leichte Wartungsschleife:

• Eine Beispielaufgabe behalten, die den Skill ausführt.
• Erwartete Dateien und Validierungsbefehle dokumentieren.
• Nach Änderungen am Skill oder Modell erneut ausführen.
• Überflüssige Anweisungen entfernen.
• Sicherheitsrelevante Aktionen optional und prüfbar halten.

Das Ziel ist nicht, den Agenten fachkundiger klingen zu lassen. Es ist, korrektes Verhalten reproduzierbar zu machen: ein kurzer Repository-Vertrag, ein gezieltes Domänenverfahren und eine ausführbare Definition of Done führen von Kontext über Änderung zu Belegen.