Der AI Unified Process (AIUP) stellt die Anforderungen ins Zentrum. Alles vor dem Code ist für jedes Team gleich; alles, was von einem Framework, einer Persistenzschicht oder einem Testwerkzeug abhängt, gehört in ein Stack-Plugin.
aiup-core schreibt den Anforderungskatalog, das Entitätsmodell, das Use-Case-Diagramm, die Use-Case-Spezifikationen und die End-to-End-Testfälle. Keines dieser Dokumente nennt ein Framework. Sein /spec-review prüft sie gegeneinander, bevor etwas implementiert wird. Sie sind die Eingabe für Ihr Stack-Plugin, und Ihr Plugin darf sie nie umschreiben.
Ein Stack-Plugin hält Ihre Architekturentscheidungen fest: Modulaufbau, Datenzugriff, UI-Technologie, Test-Frameworks und die Dokumentationsserver, die der Agent konsultieren soll. Ein Projekt installiert aiup-core und genau ein Stack-Plugin, denn Stacks teilen sich Befehlsnamen wie /implement.
Nutzen Sie die bestehenden Plugins im Marketplace-Repository als Referenzimplementierungen. aiup-vaadin-jooq ist das vollständigste; aiup-angular-jpa hat ein Praktiker gebaut, dessen Team Angular und JPA brauchte, und aiup-blazor-dotnet und aiup-nestjs-nextjs sind auf dieselbe Weise entstanden.
aiup-vaadin-jooq/flyway-migration, /implement, /browserless-test, /playwright-test, /coverage-checkaiup-angular-jpa/flyway-migration, /implement, /spring-boot-test, /vitest-test, /playwright-testaiup-blazor-dotnet/ef-migration, /implement, /dotnet-test, /bunit-test, /playwright-testaiup-nestjs-nextjs/drizzle-migration, /implement, /nest-test, /react-test, /playwright-testDer Vertrag definiert Rollen, keine feste Liste von Dateinamen. /implement und /playwright-test heissen in jedem Stack gleich, weil die anderen Skills, die Dokumentation und AI Unified Studio an sie übergeben. Die Migrations- und Test-Skills tragen den Namen ihres Werkzeugs.
Pflicht. Benannt nach Ihrem Migrationswerkzeug: /flyway-migration, /ef-migration, /drizzle-migration.
Liest das Entitätsmodell und die bereits vorhandenen Migrationen und schreibt die nächste versionierte Migration: Tabellen, Sequenzen oder Identity-Spalten, Constraints und Fremdschlüssel, referenzierte Tabellen zuerst. Sie folgt der Namensgebung, die die Datenzugriffsschicht erwartet.
Pflicht. Heisst immer /implement.
Liest eine Use-Case-Spezifikation und das Entitätsmodell und schreibt den vollständigen Schnitt dafür: UI, Service oder Endpoint, Datenzugriff und die Typen dazwischen. Er folgt den Mustern, die im Projekt bereits vorhanden sind, kompiliert das Ergebnis, schreibt keine Tests und nennt am Ende den nächsten Befehl, zum Beispiel «Next: /browserless-test UC-001».
Pflicht. Benannt nach dem Testwerkzeug: /browserless-test, /spring-boot-test, /vitest-test, /dotnet-test, /nest-test.
Schreibt eine Testklasse oder Testdatei pro Use Case und deckt die Spezifikation ab, nicht den Code: ein Test für das Hauptszenario, einer pro alternativem Ablauf (A1, A2, …) und einer pro Geschäftsregel (BR-XXX). Ein Stack mit separatem Frontend darf pro Seite einen Skill mitbringen, wie es aiup-angular-jpa und aiup-nestjs-nextjs tun.
Pflicht. Heisst immer /playwright-test.
Mit einer Use-Case-ID führt er die laufende Anwendung durch die Szenarien dieses Use Case. Mit einer Testfall-ID liest er den Testfall und jeden Use Case in dessen Flow-Tabelle und schreibt einen Journey-Test: ein Schritt pro Zeile der Flow-Tabelle, die konkreten Testdaten aus dem Testfall und ein Aufräumen, das aus den Nachbedingungen abgeleitet ist. Die Unterstützung von Testfällen ist dringend empfohlen; sie macht aus einem Geschäftsprozess einen automatisierten Regressionstest.
Empfohlen. /coverage-check plus ein Agent, der nur liest.
Ordnet jeden Schritt des Hauptszenarios, jeden alternativen Ablauf, jede Geschäftsregel, Vor- und Nachbedingung dem Code und den Tests dahinter zu, meldet Lücken und Abweichungen und schlägt den nächsten Wert für die Status-Zeile der Spezifikation vor. Sie ist das Gegenstück zu /spec-review in aiup-core auf der Seite des Stacks: Jenes prüft Spezifikationen gegeneinander, diese prüft Code und Tests gegen eine Spezifikation. Der Agent erhält nur Read, Grep und Glob: Er berichtet, er ändert nie etwas. Heute bringt nur aiup-vaadin-jooq einen mit; der Agent dort ist die Vorlage zum Kopieren.
Ein Stack-Plugin liest die Dokumente, die aiup-core schreibt, an den Orten, an denen aiup-core sie ablegt. Erfinden Sie kein zweites Format; die anforderungsgetriebene Kette funktioniert nur, wenn jeder Stack dieselben Dateien liest.
docs/requirements.mdFunktionale Anforderungen (FR-XXX), nicht-funktionale Anforderungen und Randbedingungendocs/entity_model.mdEntitäten, Attribute, Datentypen, Validierungsregeln und Beziehungendocs/use_cases/UC-*.mdEine Spezifikation pro Use Casedocs/test_cases/TC-*.mdEnd-to-End-Journeys, die mehrere Use Cases verkettenUI-Mockups, OpenAPI-Dokumente und Schemas werden vom Use Case referenziert, der sie braucht. Folgen Sie diesen Verweisen; es gibt keinen separaten Ordner zum Durchsuchen.
Jeder generierte Test nennt den Use Case, das Szenario und die Geschäftsregeln, die er prüft. Der AI Unified Process Navigator zeigt diese Verknüpfungen als Gutter-Icons in IntelliJ und VS Code, AI Unified Studio baut daraus seine Rückverfolgbarkeitsansicht, und die Abdeckungsprüfung findet damit die Tests. Ein Test ohne Markierung zählt als Lücke.
Der Test-Skill legt die Annotation an, falls das Projekt sie noch nicht hat. Die Werkzeuge erkennen sie am Kurznamen; das Package ist Ihnen überlassen.
Nur auf Testmethoden verwenden. Die Werte müssen exakt den Überschriften der Spezifikation entsprechen:
Test-Frameworks ohne Annotationen tragen dieselbe Information in den Testnamen und Tags:
Für eine andere Sprache verwenden Sie deren natives Gegenstück (ein Attribut, ein Trait, ein Tag) mit denselben drei Feldern: Use-Case-ID, Szenario und Geschäftsregeln.
UC001ManagePersonsTestUnit- oder Integrationstestklasse für einen Use Case (Java, C#)UC001ManagePersonsITBrowsertest für einen Use CaseUC-001-manage-persons.spec.tsTestdatei für einen Use Case (JavaScript, TypeScript)TC001CustomerOnboardingITJourney-Test mit dem Anzeigenamen TC-001 und einem «Step n»-Kommentar pro Zeile der Flow-TabelleProduktionscode braucht keine Pflichtmarkierung. Ein kurzer Klassenkommentar, der den Use Case nennt, und ein BR-XXX-Kommentar neben dem Code, der eine Geschäftsregel durchsetzt, machen die Abdeckungsprüfung und den nächsten Abgleich aber deutlich zuverlässiger.
Ein neues Feature, ein Change Request und ein Bug enden am selben Ort: in einer geänderten Use-Case-Spezifikation. Für keinen davon gibt es einen eigenen Befehl. Man ändert die Spezifikation und führt /implement und die Test-Befehle erneut aus; deshalb muss jeder Implementierungs- und Test-Skill bestehenden Code erkennen und an Ort und Stelle ändern.
Ein Stack-Plugin ist ein Ordner mit Skills und einem Manifest. Kopieren Sie zu Beginn das bestehende Stack-Plugin, das Ihrem am nächsten kommt, und ersetzen Sie die Technologie, nicht die Struktur.
Jede SKILL.md beginnt mit einem Namen und einer Beschreibung, die die auslösenden Formulierungen aufzählt («implement a use case», «write a migration», den Namen Ihres Frameworks). Der Rumpf folgt denselben Abschnitten wie die bestehenden Skills: Anweisungen, ein Abschnitt «If an implementation already exists» mit den obigen Abgleichsregeln, eine DO-NOT-Liste, der Ablauf und die Übergabe an den nächsten Befehl. Ein Skill darf nur auf Dateien im eigenen Ordner verlinken; legen Sie Beispiele und Referenzcode dort ab.
Trainingsdaten von Modellen hinken Framework-Releases hinterher. Deklarieren Sie in .mcp.json MCP-Server für die Dokumentation Ihres Frameworks, dazu den Playwright-Server für Browsertests, und weisen Sie die Skills an, sie zu konsultieren, bevor sie Code gegen eine API schreiben.
Damit das Plugin auch in Codex CLI, Cursor, GitHub Copilot, Gemini CLI und OpenCode läuft, ergänzen Sie das Agent-Plugins-Manifest (plugin.json und mcp.json im Plugin-Root) und das Tessl-Manifest und halten deren Versionen mit .claude-plugin/plugin.json synchron. Siehe andere KI-Coding-Werkzeuge.
Eröffnen Sie einen Pull Request gegen das Marketplace-Repository, damit jedes Team mit Ihrem Stack das Plugin mit einem Befehl installieren kann. Ein eigenes Repository funktioniert ebenfalls; ein Claude-Code-Marketplace ist nur ein Git-Repository mit einer marketplace.json.
Lassen Sie Ihr Plugin auf ein kleines Beispielprojekt los und prüfen Sie dann jeden Punkt.
Migration, /implement, Unit- oder Integrationstests und /playwright-test sind vorhanden und übergeben aneinander.
Die Skills lesen docs/entity_model.md, docs/use_cases/ und docs/test_cases/ und schreiben sie nie um.
Jeder Test nennt Use-Case-ID, Szenario und Geschäftsregeln, exakt passend zu den Überschriften der Spezifikation.
/implement zweimal auf eine unveränderte Spezifikation ändert nichts und legt keine neuen Dateien an.
Nach der Änderung eines alternativen Ablaufs ändern /implement und der Test-Skill nur den Code und die Tests für diesen Ablauf.
/playwright-test TC-001 erzeugt einen Journey-Test mit einem Schritt pro Zeile der Flow-Tabelle.
AI Unified Studio schreibt die Spezifikationen, die Ihr Stack-Plugin liest. Fordern Sie eine Einladung an, oder nehmen Sie Kontakt auf, wenn Sie Unterstützung beim Entwurf eines Plugins für Ihre Architektur möchten.