Delphi AI Skills 0.3.0: die Sprache und das Code-Audit

Die 0.3.0 von delphi-ai-skills bringt die allgemeinen Delphi-Skills, die beim Start angekündigt waren: zehn Open-Source-Skills, die Claude Code, Codex, Cursor und Gemini die Sprache und die RTL beibringen, und dazu, wie man eine Unit prüft, die seit acht Jahren niemand mehr angesehen hat.

Im letzten Absatz der ersten Ankündigung stand im Juli, dass die damaligen sieben Skills bewusst vertikal auf DelphiMVCFramework ausgerichtet waren, dass das der Anfang und nicht das Ziel war, und dass es bei den folgenden um Delphi als Plattform gehen würde. Die 0.3.0 ist der erste Teil dieses fehlenden Stücks.

Jetzt sind es zehn Skills. Zwei der drei neuen haben mit DMVCFramework nichts zu tun: Sie gelten für beliebigen Delphi-Code, für eine VCL-Form, einen Windows-Dienst, eine Bibliothek, eine Unit, die seit 2004 niemand angefasst hat.

Kurz gefasst

• delphi: die Sprache und die RTL, ohne Framework und ohne Projektlayout vorauszusetzen: Version Gating, Speicher und Lifetime, Strings, Exceptions, Generics, Threading.
• delphi-code-smells: der Audit-Durchgang über den Code, den ihr schon habt. Compiler-Warnungen, Memory Leaks, Access Violations, doppelte Frees, und zu jedem Defekt der Weg, ihn zu finden.
• dmvcframework-jsonrpc: JSON-RPC 2.0, von der Veröffentlichung der Klasse bis zum Client IMVCJSONRPCExecutor.
• Weiterhin Apache-2.0, weiterhin reines Markdown, weiterhin auf Claude Code, Codex, Cursor, Gemini CLI und jedem Agenten, der eine Datei lesen kann.
• Repository: github.com/danieleteti/delphi-ai-skills

Die Skill delphi: die, die nichts voraussetzt

Ein KI-Agent hat sehr viel mehr C# und TypeScript gelesen als Object Pascal. Das Ergebnis ist kein offensichtlich falscher Code, es ist Code, der aussieht wie Delphi. Die begin stehen an der richtigen Stelle, die Groß- und Kleinschreibung stimmt, aber drinnen steckt ein s[0], um das erste Zeichen zu lesen, ein try ... except ... finally ... end in einem einzigen Block, ein mehrzeiliger String, den es auf Delphi 11 nicht gibt, und weiteres Rauschen, das aus anderen Sprachen stammt.

Die Skill delphi deckt genau diese Schicht ab, und der Teil, der sich als Erstes bezahlt macht, ist das Version Gating. Das Modell weiß nicht, auf welcher Version ihr kompiliert, und mischt in derselben Unit verschiedene Epochen, ohne es zu merken: eine Syntax, die mit Florence gekommen ist, direkt neben einem Idiom, das man 2004 so geschrieben hat.

// Delphi 12 Athens und neuer. Auf 11 Alexandria kompiliert das nicht.
var lSql := '''
  select * from customers
  ''';

// Delphi 13 Florence und neuer: if-then-else als Ausdruck.
X := if Left < 100 then 22 else 45;

Die Skill bringt die Tabelle der CompilerVersion Release für Release mit, und davor die Regel, die sie erst nützlich macht: die Zielversion wird festgestellt, nicht angenommen. Der Agent fragt den Compiler, denn dcc32.exe --version gibt genau die CompilerVersion aus, die gebraucht wird; kommt er da nicht weiter, schaut er nach, welche Studio-Installationen vorhanden sind; und findet er mehr als eine oder gar keine, stellt er genau eine Frage: 11 Alexandria, 12 Athens oder 13 Florence? Die .dproj zählt nicht als Antwort, denn <ProjectVersion> ist die Version des Projektdateiformats, nicht die des Produkts, und ein Projekt, das zuletzt von einer alten IDE gespeichert wurde, öffnet sich unverändert in einer neuen.

Ab da passt er sich an. Auf einem bestätigten 13 Florence benutzt man das if als Ausdruck einfach, und es in ein {$IF} zu wickeln ist Rauschen. Auf 11 darf es gar nicht erst auftauchen. Und wenn die Antwort ausbleibt, schreibt die Skill für 11 Alexandria (das Minimum, das sie annimmt), setzt die Guard explizit und sagt es euch, statt euch die Entscheidung beim Kompilieren entdecken zu lassen.

{$IF CompilerVersion >= 36}    // Delphi 12 Athens und neuer
  ...
{$ENDIF}

Dann folgt der Katalog der Fehler, die ein LLM in Delphi mit fast rührender Regelmäßigkeit macht, jeder mit der richtigen Form daneben und dem Grund dahinter. Ein paar Zeilen, damit ihr eine Vorstellung bekommt:

Der Großteil des Materials liegt in sechs reference/-Dateien, die der Agent nur dann öffnet, wenn die Aufgabe es verlangt: Speicher und Lifetime, Strings und Encodings, Exceptions, Generics und RTTI, Nebenläufigkeit, Stil. Das Kontextfenster bleibt frei, bis es wirklich gebraucht wird, und genau deshalb ist eine Skill eine Datei auf der Platte und kein Block, der oben in den Chat geklebt wird.

Alles wurde aus den auf der Platte installierten RTL/VCL-Quellen kopiert oder auf der DocWiki bestätigt. Die Skill weiß außerdem, dass sie unvollständig sein kann, und wenn sie eine Signatur braucht, die sie nicht hat, steht die Reihenfolge der Schritte in ihr drin: erst die Quelle lesen, dann die DocWiki, und wenn sie dann immer noch unsicher ist, sagt sie es. Ich bin nicht sicher, ob TFoo.Bar existiert, prüf das in System.Classes.pas ist eine nützliche Antwort. Eine selbstsichere und falsche nicht.

Und sie liest den richtigen Quellbaum: Wenn ihr mit 12 Athens kompiliert, muss die Prüfung in Studio\23.0\source\rtl stattfinden, nicht in der Kopie derselben Datei unter 37.0. Die RTL wächst von Release zu Release, und ein Typ oder ein Overload, den es in Florence gibt, kann in Athens schlicht fehlen. Das gilt auch für das, was die Skills selbst mitbringen: Der DUnitX-Container, mit dem man eine Build an einem Memory Leak scheitern lässt, heißt in der mit 13 Florence ausgelieferten Version TDUnitXServiceLocator und in der mit 12 Athens ausgelieferten TDUnitXIoC, bei identischem Aufruf darunter. So ein Detail merkt man sich nicht, so ein Detail liest man nach.

Eine Deklaration ist allerdings nur die halbe Antwort. Sie sagt, wie viele Parameter es braucht und welchen Typ sie haben, und schweigt zum ganzen Rest: wer was freigibt, in welcher Reihenfolge was aufgerufen wird, wie die idiomatische Form aussieht. Dafür braucht es eine echte Aufrufstelle, und die Skills suchen sie in dieser Reihenfolge: zuerst euren Code, der auch gleich die Hauskonventionen mitbringt, die einzuhalten sind, dann die Quellen selbst (die RTL benutzt ihre eigenen APIs ständig, ein grep liefert also funktionierende Beispiele statt Dokumentationsprosa), dann die Samples des Frameworks oder die DocWiki.

Und wenn der Agent nicht weiß, wo diese Quellen liegen, lautet die Regel: fragen statt raten. Die Antwort geht am Ende der Session aber nicht verloren. Nachdem er geprüft hat, dass der Pfad existiert, schlägt der Agent vor, ihn in die Anweisungsdatei zu schreiben, die er ohnehin liest, also die CLAUDE.md des Projekts oder die AGENTS.md, in einem eigenen Block:

<!-- delphi-local-sources -->
Delphi RTL/VCL source: C:\Program Files (x86)\Embarcadero\Studio\23.0\source   (12 Athens, CompilerVersion 36.0)
DelphiMVCFramework checkout: C:\DEV\dmvcframework   (sources/ + samples/)
<!-- /delphi-local-sources -->

Dieser Block ist das Erste, was der Agent beim Start der Session anschaut, und die Frage wird einmal pro Projekt gestellt statt einmal pro Tag. Existiert ein Pfad nicht mehr, oder wechselt ihr die Delphi-Version, sagt er es und fragt erneut: Er gibt lieber zu, etwas nicht zu wissen, als etwas aus dem Gedächtnis hervorzukramen.

Die Skill delphi-code-smells: erst die Maschine, dann die Meinung

Die andere Hälfte des Berufs besteht nicht darin, Code zu schreiben, sondern sich anzusehen, was schon da ist. Genau hier schneiden die Agenten am schlechtesten ab, und nicht, weil sie sich irren, sondern weil sie höflich sind. Ihr bittet um eine Review und bekommt eine Seite voller Anmerkungen zu Variablennamen, zur Reihenfolge der uses und zur Länge der Methoden. Null Leaks. Eine Review, die fünfzehn Stilnotizen zurückgibt und kein einziges Lifetime-Problem, ist keine Review, das ist eine Meinung.

delphi-code-smells erzwingt eine Angriffsreihenfolge, und die ersten beiden Punkte kommen ganz ohne menschliches Urteil aus:

1. Mit aktiven Warnungen und Hinweisen kompilieren und jede Zeile der Ausgabe lesen. Kostenlos, objektiv, und mit dem höchsten Ertrag von allem.
2. Mit ReportMemoryLeaksOnShutdown := True ausführen, und wenn es eine Testsuite gibt, die ausführen.
3. Ownership von Hand: jedes Create in der Unit, wer es freigibt, auf welchen Pfaden, einschließlich dem, der eine Exception wirft.
4. Umgang mit Exceptions: jedes except ohne on, jeder leere Handler, jedes try/except, das ein try/finally sein wollte.
5. Nebenläufigkeit: alles, was von einem TThread.Execute oder aus dem Rumpf eines TTask.Run erreichbar ist.
6. Der Rest. Naming, with, lange Methoden, magische Zahlen.

Die Regel, die die Liste zusammenhält, steht wenig diplomatisch in der Skill: ein Leak, das der Compiler nicht sieht, schlägt eine Namenskonvention, immer. Und jeder Defekt ist mit dem zu melden, was er zur Laufzeit kostet, nicht damit, wie hässlich er zu lesen ist.

Der Defekt auf Platz eins der Rangliste ist dieser hier, und ich sehe ihn in meinen Beratungen jede Woche:

// FALSCH: der Konstruktor steht INNERHALB des try
try
  lList := TStringList.Create;
  ...
finally
  lList.Free;   // wenn Create wirft, wird hier Destroy auf nicht initialisiertem Speicher aufgerufen
end;

// RICHTIG
lList := TStringList.Create;
try
  ...
finally
  lList.Free;   // .Free ist nil-sicher: "if x <> nil then x.Free" ist Rauschen
end;

Zwei Zeilen in vertauschter Reihenfolge. Die erste Version erzeugt nur dann eine Access Violation, wenn der Konstruktor fehlschlägt, also fast nie, also am Dienstagmorgen beim Kunden, der den Server seit acht Monaten nicht neu gestartet hat.

Die Skill bringt auch den Fünf-Minuten-Durchgang mit: eine Handvoll greps, nach Ertrag sortiert, vom Konstruktor innerhalb des try über die von einem except end verschluckte Exception bis zum FreeAndNil auf einer lokalen Variablen und zum FreeOnTerminate. Es sind die Handgriffe, auf die ein Mensch keine Lust hat und die eine Maschine in drei Sekunden erledigt.

rg -n -U 'try\b[^;]*?\n\s*\w+\s*:=\s*T\w+\.Create'   # Konstruktor INNERHALB des try
rg -n -P '(?s)except\s*(//[^\n]*\n\s*)*end'          # verschluckte Exception
rg -n 'FreeOnTerminate'                              # Lifetime von Threads

Dann kommt der Teil, der aus dem Audit etwas Wiederholbares statt einer einmaligen Episode macht: wie man den Report des Memory Managers wirklich liest, wann man RegisterExpectedMemoryLeak braucht, und wie man DUnitX so konfiguriert, dass ein Leak die Build scheitern lässt. Ein einmal gefundenes Leak ist ein Arbeitstag. Ein Leak, das ab morgen die Pipeline zerlegt, ist eine geschlossene Fehlerklasse.

Eine letzte Regel, meine liebste, weil sie auch für Menschen gilt: melde nie einen Smell, von dem du nicht sagen kannst, wie man ihn findet. Wenn es keinen Warnungscode, kein Werkzeug und kein grep gibt, das ihn belegt, dann ist es eine Vorliebe, und die hatte niemand erbeten.

Und dann JSON-RPC

Die dritte neue Skill, dmvcframework-jsonrpc, kehrt in den Umkreis des Frameworks zurück: Ein JSON-RPC-2.0-Endpunkt in DelphiMVCFramework ist eine ganz normale Delphi-Klasse, die auf einem URL-Segment veröffentlicht wird, ohne Routing-Attribute pro Methode. Die Skill deckt ab, was aufrufbar ist und was nicht, den Unterschied zwischen function (Request) und procedure (Notification), benannte und positionsbasierte Parameter, die drei Ownership-Regeln dazu, wer was freigibt, die Fehlercodes, die Hooks, und den Client IMVCJSONRPCExecutor, um diesen Endpunkt aus Delphi heraus aufzurufen.

Die zehn Skills, in einer Tabelle

Die beiden Delphi-Skills haben keine Voraussetzungen: kein Projektlayout, kein Framework. Die sieben DMVCFramework-Skills gehen von einem Projekt aus, das mit dem Wizard der IDE erstellt wurde, und dmvcframework-security wird von jedem Endpunkt, der Eingaben von einem Client entgegennimmt, automatisch hereingezogen.

Installation und Verwendung

git clone https://github.com/danieleteti/delphi-ai-skills.git
cd delphi-ai-skills
install_in_claude.bat

Für Claude Code ist hier Schluss: Die Skills werden von selbst gefunden. Für die anderen Agenten gibt es install_in_codex.bat, install_in_cursor.bat und install_in_gemini.bat, die die Skills kopieren und den Verweis in die richtige Anweisungsdatei schreiben (AGENTS.md, .cursor/rules/*.mdc, GEMINI.md), weil diese Agenten sie nicht von allein entdecken. Jedes Skript nimmt einen Projektpfad entgegen, falls ihr die Skills lieber im Repository versioniert und dem ganzen Team gebt:

install_in_claude.bat C:\DEV\mein-projekt

Skills “ruft” man nicht auf: Man beschreibt die Aufgabe, und der Agent wählt aus. Der stärkste Trigger ist, die Technologie zu nennen. “Finde das Leak” ist mehrdeutig, “finde das Leak in dieser Delphi-Unit” nicht.

Kompiliert diese Unit auf Delphi 11, oder benutze ich Syntax, die es erst ab Athens gibt? Dieser Dienst verliert innerhalb weniger Tage Speicher: finde die Stelle. Mach eine Review dieser Unit und sag mir, was wirklich nicht stimmt, nicht den Stil. Welche Compiler-Warnungen ignoriere ich, hinter denen ein echter Bug steckt? Lass die Build scheitern, wenn es ein Memory Leak gibt. Dieser Code läuft in einem Thread und fasst ein VCL-Label an: was ist daran falsch? TObjectList<T> mit OwnsObjects oder ein einfaches TList<T>?

Wenn ihr die Garantie wollt, nennt ihr die Skill einfach beim Namen: in Claude Code mit /delphi oder /delphi-code-smells, bei den anderen über den Pfad (“lies skills/delphi-code-smells/SKILL.md, dann sieh dir diese Unit an”). Das funktioniert überall, weil es eine Textdatei ist und keine Funktion.

Ein Rat, der die zehn Sekunden wert ist, die er kostet: Wenn ihr die Quellen von DelphiMVCFramework auf der Platte habt, sagt es dem Agenten zu Beginn der Session (“die DMVCFramework-Quellen liegen in C:\DEV\dmvcframework”). Die Skills sind angewiesen, zu prüfen statt zu raten, und mit lesbaren Quellen in Reichweite prüfen sie sehr viel besser.

Warum die Skills keinen erfundenen Namen enthalten können

Es gibt ein grundsätzliches Problem in einem Projekt, dessen einziger Zweck es ist, einen Agenten am Erfinden von API-Namen zu hindern: Erfindet die Skill selbst einen, ist der Schaden größer als vorher, denn jetzt hat der Fehler die autoritative Aura von Dokumentation.

Deshalb erscheinen die Skills nicht, ohne eine Pipeline zu durchlaufen, die sie mit echtem Code abgleicht: den Quellen von DelphiMVCFramework und der RTL aller unterstützten Delphi-Versionen. Jeder genannte Name muss ein Name sein, den es dort drin gibt. Fehlt auch nur einer, bleibt das Release stehen, und das ist keine Meinung, über die man in der Review diskutieren kann: Entweder steht der Name in den Quellen oder er steht nicht in den Skills.

Das ist die Prüfung, die den weiter oben geschilderten Defekt beim DUnitX von 12 Athens ans Licht gebracht hat, und zwar hier statt bei euch zu Hause, was genau der Punkt ist.

Was eine solche Prüfung nicht sagen kann, ist, ob diese API gut benutzt wird: Dafür braucht es einen Compiler, und für einen Ownership-Fehler muss man das Programm ausführen. Es ist die erste der drei Ebenen, mit denen die Skills kontrolliert werden, und die einzige, die so wenig kostet, dass sie dauerhaft eingeschaltet bleiben kann.

Material und Videos auf Patreon

Die Skills sagen dem Agenten, was wahr ist. Was draußen bleibt, ist das Wie: wie eine echte Arbeitssession aussieht, wo es sich lohnt anzuhalten, was man in welcher Reihenfolge fragt, und wann der Agent gerade einen Weg einschlägt, der euch zwei Stunden kostet.

In den nächsten Wochen werde ich einiges an Material veröffentlichen, geschrieben und als Video, auf der Patreon-Seite von DelphiMVCFramework: ganze Sessions zu Delphi und zu DMVCFramework mit den Skills bei der Arbeit, samt der Stellen, an denen etwas schiefgeht, denn die sind der Teil, an dem man lernt.

Das Repository bleibt Apache-2.0 und vollständig: Nichts von dem, was ihr zum Benutzen der Skills braucht, liegt hinter einem Abo. Patreon ist der Ort für das erklärende Material, und zugleich der Weg, auf dem, wer möchte, die Arbeit an DMVCFramework und allem, was daran hängt, unterstützt. Wenn es euch nützt, der Kanal ist dieser. Wenn ihr lieber die Skills nehmt und eurer Wege geht, ist das genauso in Ordnung: Genau dafür liegen sie auf GitHub.

Häufige Fragen zu delphi-ai-skills 0.3.0

Was ist neu in der 0.3.0 von delphi-ai-skills? Drei Skills mehr als im ersten Release, insgesamt also zehn: delphi (die Sprache und die RTL, ohne jedes Framework), delphi-code-smells (die Review von bestehendem Code) und dmvcframework-jsonrpc (JSON-RPC 2.0). Die 0.3.0 korrigiert außerdem zwei falsche Aussagen in der Speicher-Reference der Skill delphi.

Muss ich DelphiMVCFramework benutzen, um diese Skills zu benutzen? Nein, und das war schon in der ersten Ankündigung so vorgesehen. delphi und delphi-code-smells setzen weder ein Framework noch ein Projektlayout voraus: Sie gelten für eine VCL-Form, einen Windows-Dienst, eine Bibliothek, eine Legacy-Unit. Die anderen sieben bleiben spezifisch für DelphiMVCFramework.

Was macht die Audit-Skill mit Delphi-Code? delphi-code-smells bringt die Review in die richtige Reihenfolge: zuerst der Compiler mit aktiven Warnungen und Hinweisen, dann die Ausführung mit ReportMemoryLeaksOnShutdown := True, dann die Ownership von Hand, die Exceptions, die Nebenläufigkeit und erst ganz am Schluss der Stil. Abgedeckt sind die Warnungen, die einen echten Bug anzeigen (mit Code, zum Beispiel W1035), $WARN und warnings-as-errors, wie man einen Leak-Report liest, wie man mit DUnitX eine Build an einem Leak scheitern lässt, die statischen Analysewerkzeuge von Drittanbietern, und ein Katalog von Defekten, in dem jeder Eintrag sagt, was er zur Laufzeit kostet und wie man ihn findet.

Kümmern sich die Skills um Sicherheit? Auf der Serverseite ja, und zwar dmvcframework-security: eine verpflichtende Abhängigkeit aller DMVCFramework-Skills, angewendet auf jeden Endpunkt, der Eingaben von einem Client entgegennimmt. Sie deckt Access Control und IDOR, Mass Assignment, SQL Injection, XSS in TemplatePro, CSRF, Path Traversal, Uploads, SSRF und Open Redirect, Security-Header, JWT-Hardening und den Umgang mit Secrets ab. delphi-code-smells ist dagegen ein Defekt-Audit, kein OWASP-Audit: Es geht um Leaks, Access Violations, doppelte Frees und still falsche Ergebnisse.

Auf welcher Delphi-Version funktionieren sie? Auf 11 Alexandria, 12 Athens und 13 Florence. Die Skill stellt fest, welche ihr habt: Sie fragt den Compiler mit dcc32.exe --version, schaut andernfalls nach, welche Studio-Installationen vorhanden sind, und wenn es mehrdeutig bleibt, fragt sie euch, welche ihr benutzt, statt zu raten. Mit bekannter Version passt sie sich an. Bleibt die Antwort aus, ist das Ziel Delphi 11 Alexandria, mit einer Guard {$IF CompilerVersion >= ...} um alles, was von der Version abhängt. Der Inhalt der Skill ist an den RTL/VCL-Quellen von Delphi 13 Florence verifiziert. Die DMVCFramework-Skills zielen auf die 3.5.0 (silicon).

Mit welchen KI-Agenten funktionieren sie? Claude Code, Codex, Cursor, Gemini CLI, Windsurf, Continue und jeder Agent, der Anweisungen in Markdown lesen kann. Das Repository enthält das Installationsskript für die ersten vier. Bei anderen Agenten als Claude Code hängt das Laden davon ab, wie sehr der Agent seine eigene Anweisungsdatei respektiert, also lohnt es sich, im Prompt die Technologie zu nennen, oder gleich die Skill selbst.

Woher weiß ich, dass die Skills keine erfundenen API-Namen enthalten? Weil sie es nicht können. Vor jedem Release gleicht eine Pipeline jeden in den Skills genannten Namen mit echtem Code ab: den Quellen von DelphiMVCFramework und der RTL der unterstützten Delphi-Versionen. Fehlt auch nur ein Bezeichner dort drin, erscheint dieses Release nicht. Das ist kein aufmerksames Gegenlesen durch jemanden, der gut ist, das ist eine Schranke: dieselbe Disziplin, die die Skills dem Agenten auferlegen, angewendet auf die Skills. Praktisch heißt das: Wenn eine Skill etwas über eine API behauptet, wurde diese Behauptung bereits mit dem Code abgeglichen und nicht mit dem Gedächtnis von irgendwem. Was die Prüfung nicht belegt, ist, dass die API gut benutzt wird: Dafür braucht es den Compiler und die Ausführung, die beiden Ebenen darüber.

Der Weg nach vorn

Wir sind immer noch bei 0.x, und die Form der Sammlung ist als instabil zu betrachten: Die Skills können geteilt, zusammengelegt, umbenannt oder entfernt werden, sobald der echte Gebrauch zeigt, was wirklich gebraucht wird. Die 1.0.0 kommt, wenn sich die Sammlung an genug echten Projekten bewährt hat. Bis dahin sind Rückmeldungen mehr wert als jede Roadmap: Wenn eine Skill euch dazu gebracht hat, falschen Code zu schreiben, ist das der Defekt, den ich zuerst sehen will.

Für Beiträge gibt es weiterhin nur ein Kriterium: jede Aussage muss an den Quellen überprüfbar sein, mit Angabe der Datei. Kein API-Name aus dem Gedächtnis. Es ist die Disziplin, die wir von den Agenten verlangen, und es wäre kurios, sie nicht auf uns selbst anzuwenden.

Das Projekt liegt hier: github.com/danieleteti/delphi-ai-skills. Issues und Pull Requests sind willkommen.

Ein Agent, der Delphi schreibt, ohne Delphi zu können, produziert Code, der schlecht kompiliert und noch schlechter altert. Ein geschulter Agent produziert Code, den ihr in zwei Jahren lesen könnt, ohne euch zu fragen, wer ihn geschrieben hat. Der Unterschied besteht vorerst aus zehn Markdown-Dateien.