Self-Repair (Selbstkorrigierende Regeln-Engine)
Eine selbstkorrigierende Gedächtnis- und Lern-Engine, die Korrekturen, Projektkonventionen und Fehlerbehebungen in einer persistenten Regelsatzdatei (autofix.json) aufzeichnet. Sie stellt sicher, dass der Agent sich kontinuierlich anpasst, wiederholte Fehler sitzungsübergreifend vermeidet und streng an Benutzerpräferenzen hält.
Warum das funktioniert: KI-Agenten neigen dazu, dieselben Standardannahmen oder Stilfehler über frische Sitzungen hinweg zu wiederholen. Durch die Externalisierung gelernter Kenntnisse in einen imperativen, versionierten JSON-Regelsatz mit strikter Priorität (neuere Regeln gewinnen) behält der Agent harte Grenzen bei, die auf den spezifischen Benutzer und das Repository zugeschnitten sind.
Speicherung & Konfiguration
Der Skill sucht die Regelsatzdatei an einem der folgenden Orte (in der Reihenfolge der Priorität):
.agents/autofix.jsonautofix.json(im Workspace-Root).rules/autofix.json
Wenn keine Datei existiert, wenn eine neue Regel hinzugefügt werden muss, erstellt er .agents/autofix.json (oder autofix.json im Root, je nach Projektkonvention).
Regelschema
Jede Regel wird in einem JSON-Array mit folgendem Schema gespeichert:
[
{
"Rule_number": 1,
"Category": "CODE",
"Instruction": "Never use default exports for React components - always use named exports.",
"Why": "Ensures consistency with the codebase and simplifies refactoring."
}
]
Erlaubte Kategorien
| Kategorie | Beschreibung | Beispiele |
|---|---|---|
[STYLE] | Code-Formatierung, Namenskonventionen, Import-Reihenfolge, Kommentare | „Immer camelCase für Hilfsfunktionen verwenden“ |
[CODE] | Sprachmuster, Bibliotheksauswahl, Typdefinitionen, Fehlerbehandlung | „Nie any in TypeScript verwenden; stattdessen unknown mit Typschutz“ |
[ARCH] | Verzeichnisstruktur, Modulgrenzen, Architekturschichten | „API-Routen befinden sich in src/server/routes/, nicht in src/api/" |
[TOOL] | CLI-Befehle, Build-Tools, Paketmanager, Test-Frameworks | „Immer pnpm anstelle von npm oder yarn verwenden“ |
[PROCESS] | Git-Workflow, Commit-Nachrichten, PR-Anforderungen, Test-Gates | „Nie Emojis zu Commit-Nachrichten hinzufügen“ |
[DATA] | Datenbankschemata, Migrationen, Caching-Strategien, Zustandsformen | „Immer created_at- und updated_at-Zeitstempel in Tabellen einfügen“ |
[UX] | UI-Verhalten, Kopierkonventionen, Barrierefreiheitsstandards | „Immer ein explizites aria-label für reine Icon-Buttons bereitstellen“ |
[OTHER] | Allgemeine projekt- oder domänenspezifische Präferenzen | „Immer öffentliche API-Endpunkte im Markdown-Tabellenformat dokumentieren“ |
Betriebsablauf
[Sitzungsstart / Aufgabe erhalten]
│
▼
┌───────────────────────────────┐
│ 1. Voraufgaben-Scan │ ◄── autofix.json lesen
│ - Alle Regeln laden │
│ - Konflikte lösen (neu>alt) │
│ - Aktive Einschränkungen │
│ aufbauen │
└───────────┬───────────────────┘
│
▼
┌───────────────────────────────┐
│ 2. Aufgabenausführung │
│ - Einschränkungen anwenden │
│ - Code / Änderungen │
│ ausführen │
└───────────┬───────────────────┘
│
├─────────────────────────────────────────┐
│ │
[Keine Korrekturen] [Auslöser erkannt]
│ │
▼ ▼
┌───────────────────────────────┐ ┌───────────────────────────────┐
│ Aufgabe abgeschlossen │ │ 3. Self-Repair & Erfassen │
│ Ausgabe an Benutzer liefern │ │ - Imperative Regel │
└───────────────────────────────┘ │ formulieren │
│ - An autofix.json anhängen │
│ - Lernen bestätigen │
└─────────────┬─────────────────┘
│
▼
┌───────────────────────────────┐
│ 4. Erneut ausführen & │
│ korrigieren │
│ Aktuelle Aufgabenausgabe │
│ korrigieren │
└───────────────────────────────┘
Detaillierte Schritt-für-Schritt-Ausführung
1. Voraufgaben-Scan (Bevor irgendetwas getan wird)
Vor der Planung oder Änderung von Dateien in einer Aufgabe:
autofix.jsonfinden und laden.- Regeln scannen:
- Prüfen, ob eine Regel direkt auf die Dateien, Werkzeuge oder Muster zutrifft, die in der aktuellen Eingabeaufforderung vorkommen.
- Konflikte lösen:
- Wenn zwei Regeln widersprüchliche Anweisungen geben, gewinnt die höher nummerierte (neuere) Regel.
- Einschränkungen aktiv halten:
- Alle aktiven Regeln als harte Einschränkungen behandeln (äquivalent zu Prompt-Vertrag
CONSTRAINTS).
- Alle aktiven Regeln als harte Einschränkungen behandeln (äquivalent zu Prompt-Vertrag
2. Wann eine Regel hinzugefügt werden soll (Auslösebedingungen)
Regelerfassung sofort auslösen, wenn einer der folgenden Fälle eintritt:
- Benutzer korrigiert Ausgabe explizit: z.B. "Nein, verwende nicht X, mach es mit Y", "Wir verwenden hier keine Klassenkomponenten".
- Benutzer lehnt eine Datei, einen Ansatz oder ein Muster ab: z.B. "Testdateien nicht neben Quellcode ablegen".
- Benutzer äußert eine persönliche/Team-Präferenz: z.B. "Commit-Nachrichten immer als Conventional Commits formatieren", "Keine Emojis in Dokumentationen".
- Ein Bug wurde durch falsche Annahmen verursacht: Der Agent hat eine Bibliothek oder einen Dateipfad angenommen, die zu einem Fehler geführt haben.
- Benutzer führt
/learnaus oder bittet, eine Regel zu merken.
3. Anhängen einer neuen Regel
Wenn ein Auslöser auftritt, führen Sie das folgende atomare Update durch:
- Vorhandenes
autofix.json-Array lesen. - Nächste sequentielle
Rule_numberermitteln:- Wenn die höchste vorhandene Regelnummer $N$ ist, ist die neue Regel $N + 1$.
- Wenn die Datei leer oder neu ist, bei
1beginnen.
- Neues Regelobjekt formatieren:
- Rule_number: Aufeinanderfolgende ganze Zahl.
- Category: Eine der Standardkategorien (
STYLE,CODE,ARCH,TOOL,PROCESS,DATA,UX,OTHER). - Instruction: Im strengen Imperativ geschrieben:
"Nie/Immer X tun - weil Y." - Why: Kurzer Grund (z.B. "Benutzerpräferenz", "Codebase-Muster", "Framework-Einschränkung").
- Regel in das JSON-Array anhängen und die Datei mit 2-Freizeichen-Einrückung speichern.
- Vorhandene Regeln niemals löschen. Wenn eine alte Regel ersetzt wird, die neue Regel so schreiben, dass ihre höhere Nummer Vorrang hat.
- Benutzer kurz benachrichtigen:
"Regel #
<N>([KATEGORIE]) gelernt:<Anweisung>— inautofix.jsonaufgezeichnet."
4. Beispiel-Regeldatei (autofix.json)
[
{
"Rule_number": 1,
"Category": "PROCESS",
"Instruction": "Never add emojis to commit messages - keep commit titles plain Conventional Commits.",
"Why": "user preference"
},
{
"Rule_number": 2,
"Category": "ARCH",
"Instruction": "Always place API route handlers in 'src/server/routes/', never in 'src/api/' - maintain consistent backend architecture.",
"Why": "existing codebase pattern"
},
{
"Rule_number": 3,
"Category": "CODE",
"Instruction": "Always use Zod schemas for input validation on all external entry points - prevent untyped runtime inputs.",
"Why": "prevents runtime errors and enforces types"
}
]
Bewährte Praktiken & Randfälle
- Atomares JSON-Schreiben: Immer das vorhandene JSON-Array parsen, das neue Objekt anhängen und gültiges JSON zurückschreiben. Die Datei niemals mit nicht escaptem Text beschädigen.
- Konkret & Imperativ: Regeln so schreiben, dass ein anderer KI sie eindeutig befolgen kann. Vage Ratschläge wie "Schreibe sauberen Code" vermeiden; stattdessen "Immer Typen zusammen mit Komponentenimplementierungen in
.types.ts-Dateien exportieren" bevorzugen. - Keine Endlosschleifen: Beim Aufzeichnen einer Regel keine separate Self-Repair-Schleife für die Regeldatei selbst auslösen.
- Ersetzende Regeln: Wenn Regel 1 besagt "Verwende Axios" und der Benutzer später anweist "Migriere alles zu Fetch", dann Regel 4 hinzufügen: "Immer natives Fetch anstelle von Axios verwenden" mit
Why: "Benutzer forderte Migration zu nativem Fetch an (ersetzt Regel 1)".