Delphi AI Skills: korrekter Delphi-Code von KI-Agenten

Code zu schreiben ist billig geworden. Teuer ist inzwischen, ihn gut schreiben zu lassen: delphi-ai-skills bringt KI-Agenten (Claude Code, Codex, Cursor, Gemini) die echte API von DelphiMVCFramework bei, mit eingebauten Vorgaben, Stil, Sicherheit und Tests.

Ab heute ist delphi-ai-skills öffentlich: eine Sammlung quelloffener Skills (Apache-2.0), die KI-Coding-Agenten beibringen, DelphiMVCFramework-Code zu schreiben, der kompiliert, den richtigen Konventionen folgt und von Anfang an sicher ist. Das funktioniert mit Claude Code, Codex, Cursor, Gemini CLI, Windsurf, Continue und mit jedem anderen Werkzeug, das Anweisungen in Markdown lesen kann.

Kurz gefasst

• Was es ist: sieben Open-Source-Skills (Apache-2.0), die einem KI-Agenten die echte API von DelphiMVCFramework 3.5.0 beibringen, statt ihn raten zu lassen.
• Für wen: alle, die REST-APIs, Minimal APIs oder Web-Apps in Delphi mit Hilfe eines KI-Agenten schreiben.
• Unterstützte Agenten: Claude Code, Codex, Cursor, Gemini CLI, Windsurf, Continue und jeder Agent, der Markdown liest.
• Installation: git clone, dann install_in_claude.bat (oder _codex, _cursor, _gemini).
• Was sich ändert: kein MapGroup mehr anstelle von Prefix, kein ToFree, das das zurückgegebene Objekt ein zweites Mal freigibt, Endpunkte, die auf den authentifizierten Benutzer gefiltert sind, und echte DUnitX-Integrationstests.
• Repository: github.com/danieleteti/delphi-ai-skills

Code ist billig geworden. Die Richtung nicht.

Dreißig Jahre lang war der teure Teil des Berufs das Tippen. Den Entwurf hatte man im Kopf, und der Flaschenhals war, ihn in Zeilen zu verwandeln: den Controller schreiben, das DTO, die Tests, den Boilerplate, das CRUD. Wer mehr korrekte Zeilen pro Stunde produzierte, war mehr wert.

Diese Knappheit ist vorbei. Heute schreibt mir ein KI-Agent in dreißig Sekunden einen kompletten CRUD-Controller samt Tests. Das ist keine Konferenz-Neuigkeit mehr, das ist der normale Arbeitstag von jemandem, der 2026 programmiert. Und wenn etwas im Überfluss vorhanden ist, verschiebt sich der Wert woanders hin.

Er verschiebt sich auf die Richtung. Wenn Code wenig kostet, dann lautet die interessante Frage nicht mehr “wie lange brauchst du dafür”, sondern:

• folgt er unseren Konventionen, oder erfindet er in jeder Session neue?
• benutzt er die API, die das Framework wirklich hat, oder die, die der Agent sich vorstellt?
• ist der Endpunkt, den er gerade generiert hat, auf den authentifizierten Benutzer gefiltert, oder liefert er die Bestellung von jedem, der eine ID in die URL schreibt?
• den Code, den ich gerade mit einem Tab-Druck akzeptiert habe: wer wartet ihn in zwei Jahren?

Genau das ist das Risiko von billigem Code: schnell sehr viel mittelmäßigen Code produzieren, beim Lesen plausibel und im Detail falsch, jeder mit seinem eigenen kleinen Stil. Ein frei laufender Agent baut technische Schulden in rasender Geschwindigkeit auf.

Die Antwort ist nicht, den Agenten zu bremsen. Sie lautet, ihn zu führen: ihm Vorgaben, Arbeitsweisen, einen Hausstil und eingebaute Sicherheitsregeln zu geben, damit der richtige Weg auch der Standardweg ist. Genau das leisten Skills.

Was eine Skill für einen KI-Agenten ist

Eine Skill ist eine Markdown-Datei, die der Agent bei Bedarf lädt, nur dann, wenn die Anfrage zu ihrer Beschreibung passt. Im Kontext des Agenten stehen dauerhaft nur der Name und eine Zeile Beschreibung, pro installierter Skill. Fragt man “erstelle einen DMVCFramework-Controller”, erkennt der Agent die Übereinstimmung und öffnet erst dann die Datei, die ihm die echte API des Frameworks erklärt: die exakten Unit-Namen, die Attribute, die Ownership-Regeln für Objekte, die Idiome, die bekannten Fallen.

Laden bei Bedarf: Die schwere Dokumentation kommt erst dann ins Spiel, wenn die Aufgabe sie verlangt.

Ein einfacher Mechanismus, aber mit einer wertvollen Eigenschaft: das Kontextfenster bleibt frei. Die Haupt-Skill dmvcframework hält in ihrer SKILL.md den operativen Kern (Bootstrap, Controller, Responses, Ownership, Middleware, typische Fehler) und verschiebt das schwere Material in reference/-Dateien, die der Agent nur öffnet, wenn die Aufgabe es verlangt: das ORM ActiveRecord, die Validierung, den Dependency-Injection-Container, die Server-Backends, dotEnv, SSE.

Das konkrete Problem: plausibler, nicht kompilierbarer Delphi-Code

Fragt einen Agenten ohne Skills nach einer Minimal API mit DelphiMVCFramework. Ihr bekommt gut geschriebenen, gut eingerückten, gut kommentierten Code, der nicht kompiliert.

Gleiche Anfrage, gleiches Modell. Links die Namen, die das Framework hätte, wenn es ASP.NET wäre, rechts die, die es wirklich hat.

Die falschen Namen sind nicht zufällig: Es sind die, die das Framework hätte, wenn es ASP.NET Core wäre, denn von ASP.NET Core hat das Modell Millionen Zeilen gelesen und von DelphiMVCFramework sehr viel weniger. So kommt MapGroup statt Prefix heraus, OkResponse statt Ok, Middleware-Klassen, die es nicht gibt, und ein ToFree um das zurückgegebene Objekt, das dieses ein zweites Mal freigibt, weil sich das Framework darum bereits kümmert.

Es gibt eine Frage, die einen ungeschulten Agenten in zehn Sekunden entlarvt:

Muss ich in einer Functional Action von DelphiMVCFramework ToFree auf dem Objekt verwenden, das ich zurückgebe?

Die richtige Antwort lautet nein: Das Framework gibt das zurückgegebene Objekt frei, und ToFree würde es ein zweites Mal freigeben. Ein Agent ohne Skills antwortet üblicherweise mit Ja, und sein Code produziert einen doppelten Free.

Jede Skill des Projekts ist genau so entstanden, dass zuerst der Fehler reproduziert wurde: Man lässt den Agenten scheitern, dokumentiert die API, die das Framework wirklich hat, stellt dieselbe Aufgabe erneut und prüft, ob er sie jetzt trifft. Kein API-Name aus dem Gedächtnis: alles verifiziert an den Quellen und den Samples von DelphiMVCFramework 3.5.0 (silicon).

Die sieben Skills für DelphiMVCFramework

Sie ergänzen sich: Die Skills für Minimal API und Web-App setzen den Kern für Entitäten, Validierung und DI als bekannt voraus, die Web-App-Skill delegiert das Markup an dmvcframework-ui und die htmx-Syntax an htmx-skill, statt beides zu duplizieren. Installiert sie alle: Der Agent wählt selbst die passenden aus.

Wer die Themen noch nicht kennt, die die Skills dem Agenten beibringen, findet hier den menschlichen Einstiegspunkt: die Minimal API von DMVCFramework, die Delphi-Web-Apps mit TemplatePro (auf Englisch) und, auf der KI-Seite, den MCP-Server für DMVCFramework mit seinem Agenten. Die Skills sind das fehlende Puzzleteil: Sie geben dem Agenten keine neuen Werkzeuge, sie geben ihm das Wissen, die vorhandenen gut zu benutzen.

Sicherheit: keine Endkontrolle, sondern eine Vorbedingung des generierten Codes

Das ist der Teil, der mir am meisten am Herzen liegt, und der Grund, warum dmvcframework-security keine Skill ist, die man am Ende der Arbeit aufruft, sondern eine verpflichtende Abhängigkeit der anderen Server-Skills: Jeder Endpunkt, der Eingaben von einem Client entgegennimmt, zieht sie herein.

Schnell generierter Code macht immer dieselben Fehler. Der häufigste, und der schwerwiegendste, ist IDOR: der Endpunkt, der der ID in der URL vertraut.

// FALSCH: jeder authentifizierte Benutzer kann die Bestellungen aller anderen lesen
function TOrdersController.GetOrder(const ID: Integer): IMVCResponse;
begin
  Result := OKResponse(TMVCActiveRecord.GetByPK<TOrder>(ID));
end;

Die ID kommt aus der URL. Nichts verknüpft sie mit dem Aufrufer. Die Regel, die die Skill dem Agenten auferlegt, lautet: Die Eigentümerprüfung ist die Query selbst, nicht ein nachgelagertes if:

function TOrdersController.GetOrder(const ID: Integer): IMVCResponse;
var
  lOrder: TOrder;
begin
  // die Eigentümerprüfung IST die Query
  lOrder := TMVCActiveRecord.GetOneByWhere<TOrder>(
    'id = ? and customer_id = ?', [ID, CurrentUserID], False);
  if lOrder = nil then
    Exit(NotFoundResponse);      // gleiche Antwort wie "gehört dir nicht": Existenz nicht verraten
  Result := OKResponse(lOrder);
end;

Der Unterschied zwischen den beiden Versionen sind drei Zeilen. Aber die erste ist eine Datenpanne, die nur darauf wartet zu passieren, und in einer Welt, in der Code mit Tab-Drücken akzeptiert wird, ist es die Version, die in Produktion landet. Eine Regel, die in einer Skill steht, ist sehr viel mehr wert als eine Regel in einer Checkliste, die niemand mehr liest: Die Skill wird angewendet, während der Code entsteht, nicht danach.

Dasselbe gilt für den Stil und für die Projektvorgaben. Die Skills lehren nicht nur “wie diese Funktion heißt”, sie lehren, wie hier gearbeitet wird. Sie schreiben zum Beispiel vor, von einem Projekt auszugehen, das mit dem Wizard der IDE erstellt wurde, statt sich einen halb korrekten Bootstrap von Grund auf auszudenken, und das Server-Backend zu respektieren, das das Projekt bereits hat: Läuft das Projekt in WebBroker unter ISAPI oder Apache, erkennen die Skills das, behalten es bei und schlagen niemals eine Migration vor.

Die Tests: das Gegengewicht zu billigem Code (DUnitX und IMVCRESTClient)

Wenn die Ära des reichlich vorhandenen Codes eine Sache wichtiger macht, nicht unwichtiger, dann sind es die Tests.

Die Überlegung ist einfach. Früher hast du den Code selbst geschrieben: Du hattest ihn Zeile für Zeile im Kopf und konntest es dir leisten (zu Unrecht, aber du konntest es), diesem Verständnis zu vertrauen. Heute kommt der Code von einem Agenten, in Mengen, und du überfliegst ihn. Das Einzige, was dir sagt, ob dieser Code wirklich das tut, was du glaubst, ist nicht mehr deine Lektüre: Es ist ein Test, der fehlschlägt. Der Test ist zu dem Ort geworden, an dem deine Absicht wohnt, und der Code ist nur noch der (inzwischen billige) Weg, sie zu erfüllen.

Und es gibt einen zweiten, noch praktischeren Grund: Der Test ist die einzige Sprache, in der sich der Agent selbst überprüfen kann. Ein Agent mit einer ausführbaren Suite schließt den Kreis (schreiben, kompilieren, Tests ausführen, korrigieren), ohne dass du bei jeder Runde den menschlichen Compiler spielen musst. Ohne Tests hat der Agent nur eine Quelle der Wahrheit: dich.

Deshalb ist dmvcframework-testing keine Nebensache. Sie bringt dem Agenten den echten Test-Stack von DelphiMVCFramework bei: DUnitX als Runner, einen IMVCServer in-process (Indy Direct) und IMVCRESTClient als fluenten HTTP-Client. Kein externer Server zum Starten, kein WebModule: Der Server entsteht und stirbt innerhalb des Tests.

function StartTestServer(APort: Integer; out AEngine: TMVCEngine): IMVCServer;
begin
  AEngine := TMVCEngine.Create(
    procedure(Config: TMVCConfig)
    begin
      Config[TMVCConfigKey.DefaultContentType] := TMVCMediaType.APPLICATION_JSON;
    end);
  AEngine.AddController(TCustomersController);

  Result := TMVCServerFactory.CreateIndyDirect(AEngine);
  Result.Listen(APort);
end;

Ein Detail, das die Installation der Skill allein schon rechtfertigt: Das funktioniert auch dann, wenn die Anwendung in Produktion als ISAPI unter IIS oder als Apache-Modul läuft. Der Host ist nicht das, was getestet wird, sondern die Engine, die Controller und die Middleware. Ein ungeschulter Agent versucht, wenn man ihn um Tests für ein WebBroker-Projekt bittet, IIS zu starten.

Die Integrationstests sind echtes HTTP gegen den in-process laufenden Server, und die Skill schreibt vor, auf Statuscode und Body zu assertieren, nicht darauf, dass der Aufruf nicht explodiert ist:

procedure TCustomersTests.Create_Returns201_And_Location;
var
  lResp: IMVCRESTResponse;
begin
  lResp := FClient.Post('/api/customers',
    '{"firstName":"Daniele","lastName":"Teti","email":"d.teti@example.com"}');

  Assert.AreEqual(HTTP_STATUS.Created, lResp.StatusCode);
  Assert.IsNotEmpty(lResp.HeaderValue('Location'));
end;

procedure TCustomersTests.Post_Invalid_Email_Returns422;
var
  lResp: IMVCRESTResponse;
begin
  lResp := FClient.Post('/api/customers',
    '{"firstName":"Bob","lastName":"X","email":"not-an-email"}');
  // Validierung fehlgeschlagen => 422, und die Action lief nie
  Assert.AreEqual(HTTP_STATUS.UnprocessableEntity, lResp.StatusCode);
end;

Aber der Teil, der mich wirklich interessiert, ist ein anderer, und es ist der Punkt, an dem sich die Test-Skill und die Sicherheits-Skill die Hand geben. Testet das Schloss, nicht nur den Schlüssel. Für jede geschützte Ressource ist der entscheidende Test nicht der, der prüft, dass der Eigentümer eine 200 bekommt: Es ist der, der prüft, dass alle anderen nicht hinkommen.

procedure TSecureTests.NoToken_Returns401;
begin
  // der Test, der das vergessene [MVCRequiresAuthentication] auffliegen lässt
  Assert.AreEqual(HTTP_STATUS.Unauthorized, FClient.Get('/api/admin/stats').StatusCode);
end;

procedure TOrdersTests.User_Cannot_Read_Another_Users_Order;
begin
  // Bestellung 1 gehört user1
  FClient.SetBearerAuthorization(TokenFor('user2'));
  // 404, nicht 403: eine 403 würde die Existenz der Bestellung bestätigen
  Assert.AreEqual(HTTP_STATUS.NotFound, FClient.Get('/api/orders/1').StatusCode);
end;

Das ist der IDOR-Test, also genau die Lücke aus dem vorherigen Abschnitt, in drei Zeilen eingefangen. Es ist auch der Test, den fast niemand schreibt, weil eine 200 für den Eigentümer das beruhigende Gefühl gibt, der Endpunkt “funktioniere”. Die Regel, die die Skill dem Agenten auferlegt, ist eindeutig: für jedes Verb jeder Ressource, die einen Eigentümer hat, braucht es den Test, der zeigt, dass ein anderer Benutzer abgewiesen wird. Ein sauber gefiltertes GET und ein offen gelassenes DELETE sind trotzdem eine Datenpanne.

Genau darum geht es: Auf die Bitte “schreibe die Integrationstests für die Customers-Endpunkte, inklusive der Autorisierungsfälle” produziert der Agent nicht einfach ein paar Tests, er produziert die Tests, auf die ihr keine Lust gehabt hättet. Und das ist genau die Art von Arbeit, in der billiger Code ein echter Segen ist, statt eine elegante Methode, Schulden anzuhäufen. Die Skill bringt auch scripts/run-tests.bat mit, sodass der Agent die Suite selbst kompiliert und ausführt und das Rot sieht, bevor er euch sagt, er sei fertig.

Delphi AI Skills in Claude Code, Codex, Cursor und Gemini installieren

Klont das Repository und startet das Skript eures Agenten (Windows):

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

Für Claude Code braucht es nicht mehr: Die Skills werden von selbst gefunden. Für Codex, Cursor und Gemini CLI gibt es install_in_codex.bat, install_in_cursor.bat und install_in_gemini.bat, die die Skills kopieren und den Verweis in die Anweisungsdatei des Agenten 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 installiert und für das ganze Team versioniert:

install_in_claude.bat C:\DEV\mein-projekt

Danach wird das Projekt mit dem Wizard der IDE erstellt (File → New → Other → Delphi Projects → DelphiMVCFramework), einmal kompiliert, der Agent in diesem Ordner gestartet und gefragt, was gebraucht wird:

Füge einen Customers-Controller mit vollständigem CRUD hinzu, gestützt auf eine ActiveRecord-Entität für die Tabelle customers

Ein letzter Rat, der einen deutlichen Unterschied macht: Wenn ihr die Quellen von DelphiMVCFramework auf der Platte habt, sagt es dem Agenten (“die DMVCFramework-Quellen liegen in C:\DEV\dmvcframework”). Die Skills wissen, dass sie unvollständig oder veraltet sein können, und sind in diesem Fall angewiesen, zu verifizieren statt zu raten: Sie lesen die Quellen und die Samples, und wenn sie dann immer noch unsicher sind, sagen sie es, statt etwas zu erfinden.

Eine echte Session, von Anfang bis Ende

Die Theorie ist zu Ende. So sieht eine echte Session in einem vom Wizard erzeugten Projekt aus, mit Claude Code. Man “ruft” nie eine Skill auf: Man beschreibt die Aufgabe, und die Skill lädt sich von selbst.

$ cd C:\DEV\OrdersAPI
$ claude

> füge einen Customers-Controller mit vollständigem CRUD hinzu, gestützt
  auf eine ActiveRecord-Entität für die Tabelle customers

● Skill(dmvcframework)
  ⎿  SKILL.md geladen
  ⎿  reference/activerecord.md geöffnet (Entität + Mapping)
● Skill(dmvcframework-security)
  ⎿  SKILL.md geladen (der Endpunkt nimmt Eingaben vom Client entgegen)

● Read(EngineConfigU.pas)    Wizard-Projekt erkannt, Backend Indy Direct
● Read(Controllers.Base.pas) Hausstil: Functional Action, IMVCResponse

● Write(Entities.Customer.pas)
● Write(Controllers.Customers.pas)
● Edit(EngineConfigU.pas)     +1 Zeile: AddController(TCustomersController)

  Fertig. Hinweise:
  - GET /api/customers/($id) ist auf den authentifizierten Kunden gefiltert,
    nicht nur auf die ID: ein Benutzer kann die Zeile eines anderen nicht lesen.
  - Das von OKResponse zurückgegebene Objekt wird vom Framework freigegeben:
    kein ToFree, das wäre ein doppelter Free.
  - Das Feld "id" ist von der Deserialisierung ausgeschlossen (Mass Assignment).

Die drei abschließenden Hinweise sind keine Höflichkeit: Es sind die Regeln der Skills, die gearbeitet haben, während der Code entstand. Ein Agent ohne Skills hätte euch beim gleichen Prompt ein ungefiltertes GetByPK(ID) geliefert, ein ToFree zu viel und ein DTO, das sich die id vom Client schreiben lässt.

Es geht in derselben Unterhaltung weiter, und die Test-Skill betritt von selbst die Bühne:

> schreibe jetzt die Integrationstests, inklusive der Autorisierungsfälle

● Skill(dmvcframework-testing)
  ⎿  SKILL.md geladen

● Write(Tests.Server.pas)      IMVCServer in-process, kein WebModule
● Write(Tests.Customers.pas)   9 Tests: CRUD, 404, 422, 401, IDOR
● Bash(scripts\run-tests.bat)
  ⎿  Running... 9 tests, 8 passed, 1 FAILED
     [FAIL] User_Cannot_Read_Another_Users_Order
            expected 404, got 200

  Der IDOR-Test schlägt fehl: OrdersController.GetOrder sucht immer noch
  nur nach PK. Ich korrigiere das (es lag außerhalb des Rahmens, den du mir
  gegeben hast, bestätigst du?)

Das ist der Punkt, an dem sich der Kreis schließt: Ein vom Agenten geschriebener Test hat eine Lücke in Code gefunden, den der Agent nicht geschrieben hatte. Mit reiner Codegenerierung wäre dieser Bug einfach liegen geblieben. Genau deshalb sind in einer Welt des billigen Codes Vorgaben und Tests mehr wert als Geschwindigkeit.

Dieselbe Arbeit mit Codex, Cursor, Gemini oder einem beliebigen anderen Agenten

Die Skills sind reines Markdown, ohne proprietäre Syntax: Der Inhalt ist bei allen Agenten identisch, es ändert sich nur die Art, wie der Agent erfährt, dass diese Dateien existieren.

Mit Codex sieht dieselbe Session wie folgt aus: Die Anfrage ist identisch, es ändert sich nur die Spur, mit der der Agent erklärt, die Skill gelesen zu haben.

$ codex
> füge einen Customers-Controller mit vollständigem CRUD hinzu (DMVCFramework)

  Ich lese skills/dmvcframework/SKILL.md, wie von AGENTS.md verlangt.
  Dieser Endpunkt nimmt Eingaben vom Client entgegen: ich lese auch
  skills/dmvcframework-security/SKILL.md.
  ...

Achtung, ein Detail: Bei anderen Agenten als Claude Code ist das Laden nicht garantiert, es hängt davon ab, wie sehr der jeweilige Agent seine eigene Anweisungsdatei respektiert. Deshalb lohnt es sich bei Codex, Cursor oder Gemini, das Framework im Prompt zu nennen (“erstelle einen DMVCFramework-Controller”, nicht “erstelle einen Controller”): Das ist der stärkste Trigger. Und wenn ihr vermutet, dass die Skill nicht geladen wurde, sagt es explizit:

Benutze die Skill dmvcframework. Erstelle dann den Controller für Orders.

Es gibt auch einen Zehn-Sekunden-Weg, um herauszufinden, ob der Agent vor euch geschult ist oder nicht. Fragt ihn:

Muss ich in einer Functional Action von DelphiMVCFramework ToFree auf dem Objekt verwenden, das ich zurückgebe?

Antwortet er nein, weil das Framework das zurückgegebene Objekt bereits freigibt und ToFree es ein zweites Mal freigeben würde, ist die Skill aktiv. Antwortet er mit Ja, produziert sein Code einen doppelten Free, und ihr werdet es in Produktion herausfinden.

Häufige Fragen zu delphi-ai-skills

Was ist delphi-ai-skills? Es ist ein Open-Source-Projekt (Apache-2.0), das sieben Skills für KI-Coding-Agenten bündelt, gewidmet DelphiMVCFramework. Eine Skill ist eine Markdown-Datei, die der Agent bei Bedarf lädt und die ihm die echte API des Frameworks beibringt: Units, Attribute, Ownership-Regeln für Objekte, Idiome und bekannte Fallen.

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 Installationsskripte für die ersten vier.

Warum schreibt ein KI-Agent ohne Skills Delphi-Code, der nicht kompiliert? Weil er aus dem Gedächtnis schreibt und auf die Muster der Frameworks zurückfällt, die er sehr viel häufiger gesehen hat, typischerweise ASP.NET Core. So erzeugt er plausible, aber nicht existierende Namen, zum Beispiel MapGroup statt Prefix oder OkResponse statt Ok, und ein ToFree auf dem zurückgegebenen Objekt, das einen doppelten Free verursacht, da sich bereits das Framework um die Freigabe kümmert.

Kümmern sich die Skills auch um Sicherheit? Ja, und das ist der wichtigste Teil. dmvcframework-security ist eine verpflichtende Abhängigkeit aller Server-Skills: Sie gilt für 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.

Können die Skills auch Tests schreiben? Ja, mit dem echten Test-Stack des Frameworks: DUnitX als Runner, einen IMVCServer in-process mit Indy Direct und IMVCRESTClient als HTTP-Client, ohne externe Server und ohne WebModule, auch wenn die Anwendung in Produktion als ISAPI oder als Apache-Modul läuft. Abgedeckt sind CRUD-Tests, Authentifizierungstests und Autorisierungstests (IDOR).

Erstellen die Skills das Delphi-Projekt von Grund auf? Nein, und das ist eine bewusste Entscheidung. Das Projekt wird mit dem Wizard der IDE erstellt, einmal kompiliert, und erst dann startet man den Agenten in diesem Ordner. Die Skills erkennen das Layout des Wizards und ergänzen Funktionalität darin, statt einen halb korrekten Bootstrap zu erfinden.

Funktionieren sie in einem bestehenden WebBroker- oder ISAPI-Projekt? Ja. Das Standard-Backend für ein neues Projekt ist Indy Direct, aber ein bestehendes WebBroker-Projekt (ISAPI unter IIS, Apache-Modul) wird vollständig unterstützt: Die Skills erkennen den Host, behalten ihn bei und schlagen niemals eine Migration vor. Alles, was oberhalb des Hosts liegt, also Controller, Routing, ActiveRecord, Validierung, DI und Middleware, ist auf jedem Backend identisch.

Version 0.1.0 der Delphi AI Skills, und der Weg nach vorn

Es ist ein erstes Release. Die Skills sind auf DelphiMVCFramework 3.5.0 geschrieben und verifiziert, aber sie haben noch nicht Dutzende echte Projekte durchlaufen: Rechnet mit ein paar Kanten, und meldet sie bitte. Solange wir bei 0.x sind, ist auch die Form der Sammlung selbst als instabil zu betrachten: Die Skills können geteilt, zusammengelegt, umbenannt oder entfernt werden, sobald der echte Gebrauch zeigt, was wirklich gebraucht wird.

Für Beiträge gibt es nur ein Kriterium, und es ist nicht verhandelbar: Jede Aussage muss an den Quellen oder an einem Sample von DelphiMVCFramework überprüfbar sein, mit Angabe der Datei. Kein API-Name aus dem Gedächtnis, niemals. Es ist genau 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.

Code zu schreiben ist inzwischen der einfache Teil. Zu entscheiden, welchen Code man will, und dafür zu sorgen, dass genau der herauskommt, auch wenn ihn eine Maschine schreibt, ist der Beruf, der bleibt. Genau dafür sind die Delphi AI Skills da: einem KI-Agenten die Vorgaben, den Stil, die Sicherheit und die Tests zu geben, mit denen Delphi-Code entstehen soll.