Die Agent-Plugins decken den Workflow des AI Unified Process von Anfang bis Ende ab, in Claude Code, Codex, Cursor, Copilot und anderen Agenten. Der AI Unified Process Navigator hält die entstehenden Spezifikationen und Tests in Ihrer IDE verbunden. Und AI Unified Process Studio erlaubt allen Stakeholdern einen Blick auf das Projekt, direkt aus dem Git Repository.
Open-Source-Plugins, die den AI-Unified-Process-Workflow in Ihrem Coding-Agenten vorantreiben: Anforderungen erfassen, Entitäten modellieren, Use Cases spezifizieren sowie Implementierung und Tests generieren.
Enthält das stack-unabhängige aiup-core Plugin und zehn Layer-Plugins, eines pro technischer Schicht, die Sie pro Projekt kombinieren: für Java aiup-flyway, aiup-jooq oder aiup-jpa, aiup-spring-boot, aiup-vaadin oder aiup-angular, für TypeScript aiup-drizzle, aiup-nestjs und aiup-nextjs, und aiup-playwright für beide. C# + Blazor gibt es als kombiniertes Stack-Plugin.
Der AI Unified Process Navigator ist ein eigenständiges IDE-Plugin, verfügbar für IntelliJ und Visual Studio Code, das mit @UseCase annotierte Testmethoden über Gutter-Symbole mit ihren UC-XXX-*.md-Spezifikationen verknüpft, und vom Spec zurück zum Test.
Funktioniert unabhängig vom Coding-Agenten, ergänzt aber die Plugins ideal: Spezifikationen und Tests mit Ihrem Agenten generieren und anschliessend in Ihrer IDE navigieren.
Ein webbasierter Arbeitsplatz, der allen Stakeholdern einen Blick auf Projekte nach dem AI Unified Process erlaubt: strukturierte Editoren für Anforderungen, Entity Model und Use-Case-Spezifikationen, mit automatisch generierten Diagrammen.
Alle Artefakte liegen in Ihrem Git Repository auf GitHub oder Bitbucket: dieselben Dateien, die auch die Plugins erzeugen und konsumieren, ohne Konvertierung. Zurzeit in privater Beta; der Zugang erfolgt auf Einladung.
Jedes Projekt installiert aiup-core, den stack-unabhängigen Kern für Requirements Engineering, der auch die Konstruktion steuert. Implementierung und Tests kommen aus Layer-Plugins, eines pro technischer Schicht, pro Projekt kombiniert: Eine REST-API ohne UI ist ebenso möglich wie eine Vaadin-Flow-UI mit einer REST-API daneben. Anderer Stack? Erstellen Sie Ihr eigenes Stack-Plugin.
Stack-unabhängiges Methodik-Plugin mit Vorlagen für anforderungsgetriebene Entwicklung. Seine Spezifikationsbefehle funktionieren mit jedem Technologie-Stack; seine sechs Konstruktionsbefehle führen die Layer-Plugins Ihres Projekts aus; seine drei Übergangsbefehle übergeben das System mit Abnahmeprotokoll, Benutzerhandbuch und Release Notes.
/requirements
– Anforderungskatalog erstellen
/entity-model
– Entitätsmodell mit ER-Diagrammen erstellen
/use-case-diagram
– PlantUML-Use-Case-Diagramm generieren
/use-case-spec
– Use-Case-Spezifikation schreiben
/business-process
– Geschäftsprozess in BPMN 2.0 aus den Anforderungen und dem Use-Case-Diagramm modellieren: eine Lane pro Akteur, ein Use Case pro Aktivität
/test-case
– End-to-End-Testfall schreiben, der mehrere Use Cases verkettet, oder je Pfad eines Geschäftsprozesses (BP-*) einen Testfall ableiten
/reverse-engineer
– Bestehendes Projekt in Artefakte des AI Unified Process überführen
/spec-review
– Spezifikationen gegeneinander prüfen: ein deterministischer Lint, der den Build stoppen kann, dazu ein beratendes Review auf Widersprüche, Lücken und Mehrdeutigkeiten, eine Traceability-Matrix mit Anforderungsabdeckung und ein HTML-Report
/next
– Unsicher, welcher Befehl als Nächstes kommt? Er liest den Stand des Projekts, die Use Cases und Testfälle pro Status, die offenen Fragen, die Stack-Datei, den Spec-Lint und den letzten Git-Tag, und nennt den nächsten Befehl mit Begründung. Nur lesend: Er führt den Befehl nie selbst aus
/open-questions
– Die Fragen, die die Spezifikation noch nicht beantwortet, in docs/open_questions.md (OQ-*) festhalten: erfassen, auflisten, beantworten und zurückziehen, damit ein Product Owner jede Lücke an einem Ort beantwortet
/architecture-decision
– Architekturentscheidungen (ADR-*) in docs/architecture/decisions/ festhalten, jede mit den nicht-funktionalen Anforderungen und Randbedingungen verknüpft, denen sie dient, gegen die akzeptierten Entscheidungen geprüft und abgelöst statt umgeschrieben, damit eine geänderte Qualität oder Randbedingung zeigt, welche Entscheidungen zu überprüfen sind
/stack
– In der Stack-Datei festhalten, welches Layer-Plugin welche Schicht baut und testet, immer unter docs/architecture/stack.md. Bestehende Architekturdokumentation (arc42, C4, 4+1 oder ein docs/architecture.md) wird als Eingabe gelesen und nie verändert. Auf Wunsch legt er auch docs/architecture/decision-rights.md mit den Standard-Entscheidungsrechten an
/use-case-implement
– Use Case implementieren, indem die Layer-Skills von unten nach oben laufen, von der Migration bis zur UI, und jeder dem nächsten übergibt, was er gebaut hat, im Rahmen der Entscheidungsrechte des Projekts (was der Agent allein entscheidet, zuerst erfragt oder nie tut); der Bericht listet die Entscheidungen, die er allein getroffen hat
/use-case-test
– Use Case einmal testen, in der Integrationsschicht, die die Stack-Datei für seine Einstiegsschicht nennt: der Schicht, deren Tests im Prozess gegen die echte Datenbank laufen. Danach folgen die End-to-End-Tests, wenn der E2E-Umfang der Stack-Datei Use Cases einschliesst
/use-case-coverage
– Use Case gegen seine Spezifikation prüfen und die Abdeckungsmatrix ausgeben, für jede Kombination von Layer-Plugins; ersetzt /coverage-check. Der Befehl startet den schreibgeschützten Sub-Agent uc-coverage-layered, den auch /test-case-coverage für eine Journey nutzt
/test-case-implement
– Eine Testfall-Journey (TC-*) als einen End-to-End-Test automatisieren, mit dem End-to-End-Test-Skill der Stack-Datei
/test-case-coverage
– Einen Journey-Test gegen seinen Testfall prüfen: hinter welchen Flow-Zeilen, Validierungen und Nachbedingungen ein Testschritt steht
Ein Use Case kann seine Einstiegsschichten in einer optionalen Zeile Schichten: nennen: UI, API oder Service. /use-case-implement baut dann nur diese, /use-case-test testet in der Integrationsschicht, die die Stack-Datei für die erste davon nennt, und /use-case-coverage meldet für ausgelassene Schichten keine Lücke. So kann ein Projekt manche Use Cases in einer Vaadin-Flow-UI anbieten, andere über eine REST-API und manche über beide.
Ein Use Case kann zudem seine Mockups in einer optionalen Zeile Mockup: verlinken: eine Figma-Datei, ein Bild oder eine Markdown-Skizze. Die UI-Layer-Skills übernehmen daraus das Layout, die Reihenfolge der Felder, die Spalten eines Grids, wo die Aktionen stehen; für die Felder, die Regeln und die Meldungen bleibt die Spezifikation massgebend, und eine Abweichung wird zur nicht blockierenden offenen Frage.
Ein Use Case, der einem Partnersystem angeboten wird, kann die Operationen des mit ihm vereinbarten API-Vertrags in einer optionalen Zeile API: verlinken: die OpenAPI-Datei mit der operationId als Fragment. Anders als ein Mockup ist der Vertrag verbindlich: In einem Contract-first-Projekt baut und testet die API-Schicht die Operation wie geschrieben, und ein Widerspruch zur Spezifikation wird zur blockierenden offenen Frage statt zu einer Wahl des Agenten.
/acceptance-protocol
– Eine Abnahmerunde aus den Testfällen durchführen: pro Testfall eine Checkliste mit Ergebnis, Tester, Datum und Bemerkung in docs/acceptance/, die Ergebnisse der Tester wörtlich festgehalten, und beim Abschluss die Use Cases, deren Zeilen alle bestanden sind, nach Ihrer Bestätigung auf Done gesetzt. Für eine fehlgeschlagene Zeile nennt er beide Korrekturen, Code oder Spezifikation, und überlässt Ihnen die Wahl
/user-guide
– Das Benutzerhandbuch in docs/user_guide/ aus den getesteten und abgenommenen Use Cases schreiben: ein Kapitel pro Akteur, eine Aufgabe pro Use Case in den Begriffen des Glossars, keine Masken oder Schaltflächen, die die Spezifikation nicht nennt; Abschnitte, die das Team von Hand ergänzt, bleiben bei jedem Lauf erhalten
/release-notes
– Fachliche Release Notes in docs/release-notes.md aus den Spezifikationen statt aus Commit-Nachrichten: die Use Cases, die seit dem letzten Git-Tag Done erreicht haben, die abgenommenen, die sich geändert haben, die obsolet gewordenen und die Anforderungen, die Verified erreicht haben
Seit Marketplace 3.0 kommt die Konstruktion als Layer-Plugins. Wählen Sie ein Plugin pro technischer Schicht Ihres Projekts: /stack hält die Kombination fest, /use-case-implement und /use-case-test führen die Layer-Skills der Reihe nach aus. Jeder Layer-Skill läuft auch für sich allein, zum Beispiel /jooq-persistence UC-001. Die Layer-Plugins brauchen aiup-core 3.0.0 oder neuer, die TypeScript-Plugins 3.14.0.
Migrationsschicht. Versionierte Flyway-SQL-Migrationen aus dem Entitätsmodell: Sequenzen, Tabellen, Constraints und Fremdschlüssel. /use-case-implement führt den Skill nur aus, wenn ein Use Case eine Entität ohne Tabelle braucht oder eine, deren Tabelle hinter dem Entitätsmodell zurückliegt. Die Einheit ist die Entität: Eine neue Tabelle erhält alle Attribute und Constraints, die das Entitätsmodell ihr gibt.
/flyway-schema
– Migrationsskripte für einen Use Case erstellen, oder für jede Entität, die im Schema noch fehlt
Persistenzschicht mit jOOQ. Typsichere Repositories über den Klassen, die jOOQ aus den Migrationen generiert: Projektionen in Java Records, MULTISET für verschachtelte Collections, Paging, dynamische Filter und optimistisches Locking.
/jooq-persistence
– Repositories und Abfragen erstellen, die ein Use Case braucht
/jooq-persistence-test
– Abfragen mit eigener Logik gegen eine echte Datenbank testen
Persistenzschicht mit Spring Data JPA und Hibernate. Entitäten, die auf das Flyway-Schema abgebildet werden, Repositories, Abfragen und Projektionen; in einem hexagonalen Backend auch der Outbound-Port und sein Adapter. Hibernate validiert das Schema nur, es erzeugt es nie.
/jpa-persistence
– Entitäten, Repositories und Abfragen erstellen, die ein Use Case braucht
/jpa-persistence-test
– @DataJpaTest-Repository-Tests mit Testcontainers erstellen
Service-, REST-API- und Client-Schicht einer Spring-Boot-Anwendung: Geschäftslogik mit Transaktionen und Geschäftsregeln, eine REST-API mit RFC 9457 Problem Details, die eine vereinbarte OpenAPI-Operation wie geschrieben baut, sowie Port und Adapter für jedes Fremdsystem, das ein Use Case aufruft. Hilla, Angular und eine REST-API bauen auf der Service-Schicht auf; eine Vaadin-Flow-UI, die die einzige Einstiegsschicht ist, darf sie auslassen und die Repositories aufrufen.
/spring-service
– Service-Methoden, Transaktionsgrenzen, Geschäftsregeln und Domain-Exceptions erstellen
/spring-rest
– REST-Endpunkte, Request- und Response-DTOs, Problem Details, Statuscodes und Paging erstellen
/spring-client
– Port und Adapter erstellen, die ein Fremdsystem so aufrufen, wie sein OpenAPI- oder AsyncAPI-Vertrag es festlegt
/spring-service-test
– Jede Geschäftsregel mit erlaubtem und abgewiesenem Fall testen
/spring-rest-test
– Statuscodes, JSON-Vertrag und Problem Details über den ganzen Stack testen
/spring-client-test
– Den Adapter gegen einen Stub des Vertrags testen und ein Fake des Ports für die Tests darüber schreiben
UI- und End-to-End-Schicht einer Vaadin-Anwendung. Serverseitige Java-Views mit Vaadin Flow auf der Service-Schicht, oder ohne sie auf den Repositories, oder React-Views mit Hilla auf der Service-Schicht, und Browser-Tests mit Playwright und Drama Finder.
/vaadin-flow-ui
– Vaadin-Flow-Views, Grids, Binder-Formulare und Dialoge erstellen
/hilla-ui
– Hilla-Endpunkt, der an den Service delegiert, und die React-View erstellen
/vaadin-flow-ui-test
– Browserless-View-Tests gegen den echten Service und die echte Datenbank erstellen, die Integrationsschicht eines Flow-Projekts
/hilla-ui-test
– Vitest-View-Tests mit gemocktem Endpunkt erstellen, dazu einen Vertragstest des Endpunkts
/vaadin-e2e-test
– Playwright- und Drama-Finder-Tests für einen Use Case (UC-*) oder einen Testfall (TC-*) erstellen
UI-Schicht mit einem Angular-Client: Standalone-Seiten und -Komponenten, signal()-State, HttpClient-Services und TypeScript-Modelle, die Feld für Feld aus den DTOs der API-Schicht geschrieben werden. Angular spricht nur über HTTP mit dem Backend, deshalb hat das Projekt immer eine API-Schicht, etwa /spring-rest.
/angular-ui
– Seiten, Komponenten, Services und Routen eines Use Case erstellen
/angular-ui-test
– Vitest-Komponenten- und Service-Tests mit TestBed und HttpTestingController erstellen
End-to-End-Schicht für jede Web-UI. Playwright-Tests in TypeScript gegen die laufende Anwendung, die Elemente über Rolle, Label und Text finden und deshalb mit jeder UI funktionieren, die semantisches HTML und ARIA rendert. Eine Vaadin-UI verwendet stattdessen /vaadin-e2e-test.
/playwright-e2e-test
– Einen Test pro Szenario eines Use Case erstellen, oder einen Testschritt pro Ablaufzeile eines Testfalls
Migrations- und Persistenzschicht eines TypeScript-Backends mit Drizzle ORM über PostgreSQL. Das Schema entsteht aus dem Entitätsmodell, die Migrationen werden mit drizzle-kit generiert und nie von Hand geschrieben, und die Repositories verantworten die Transaktionen. Baut auf aiup-nestjs auf.
/drizzle-schema
– Das Drizzle-Schema eines Use Case schreiben und die SQL-Migration generieren
/drizzle-persistence
– Die Repositories und Abfragen erstellen, die ein Use Case braucht
/drizzle-persistence-test
– Repository-Tests gegen PostgreSQL in Testcontainers erstellen
Service- und API-Schicht mit NestJS: Services mit den Geschäftsregeln und Domain-Fehlern, Controller mit class-validator-DTOs und RFC 9457 Problem Details, und eine vereinbarte OpenAPI-Operation, genau wie geschrieben gebaut.
/nest-service
– Die Geschäftsregeln eines Use Case in NestJS-Services umsetzen
/nest-rest
– Die Controller, DTOs und Fehlerantworten eines Use Case erstellen
/nest-service-test
– Service-Tests für jede Geschäftsregel gegen eine echte Datenbank erstellen
/nest-rest-test
– API-Tests mit Supertest durch den ganzen Stack erstellen
UI-Schicht mit einem Next.js-App-Router-Client. Next.js spricht nur über HTTP mit dem Backend, auch Server Components und Server Actions, deshalb hat das Projekt immer eine API-Schicht, etwa /nest-rest oder /spring-rest.
/nextjs-ui
– Die Routen, Komponenten und Vertragstypen eines Use Case erstellen
/nextjs-ui-test
– Vitest-Komponententests mit React Testing Library erstellen
REST-API, Spring Boot, jOOQ – aiup-flyway, aiup-jooq, aiup-spring-bootREST-API, Spring Boot, JPA – aiup-flyway, aiup-jpa, aiup-spring-bootVaadin Flow oder Hilla, jOOQ – aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadinVaadin Flow und eine REST-API, jOOQ – aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadin; die Zeile Schichten: jedes Use Case sagt, ob er in der UI, über die API oder über beide angeboten wirdAngular, Spring Boot, JPA – aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-angular, aiup-playwrightREST-API, NestJS, Drizzle – aiup-drizzle, aiup-nestjsNext.js, NestJS, Drizzle – aiup-drizzle, aiup-nestjs, aiup-nextjs, aiup-playwrightNext.js, Spring Boot, JPA – aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-nextjs, aiup-playwrightVerwenden Sie in einem Projekt entweder Layer-Plugins oder ein kombiniertes Stack-Plugin, nie beides: Die kombinierten Plugins lesen die Stack-Datei nicht. Der Leitfaden zu den Layer-Plugins erklärt die Stack-Datei, die Übergabe zwischen den Schichten und die Integrationsschicht und hilft Ihnen, Ihre Kombination zu wählen.
Eine neue Technologie braucht ein Layer-Plugin mit einem oder zwei Skills, kein ganzes Stack-Plugin. Beiträge sind willkommen! Fügen Sie Ihre eigenen Plugins hinzu, um der Community zu helfen.
/use-case-implement und /use-case-test führen bereits jede Schicht eines Use Case mit einem Befehl aus, doch die Schritte von den Anforderungen bis zu den Tests rufen Sie noch einzeln auf. Wir arbeiten daran, den AI Unified Process durchgehend zu automatisieren, damit die Kette mit deutlich weniger manuellen Befehlsaufrufen abläuft.
Vor Marketplace 3.0 kam jeder Stack als ein Plugin, dessen /implement UI, Backend und Datenzugriff gemeinsam baute. Drei davon sind zugunsten der Layer-Plugins veraltet; aiup-blazor-dotnet bleibt dauerhaft kombiniert.
Kombiniertes Plugin für Java-Webanwendungen mit Vaadin Flow oder Hilla und jOOQ.
Veraltet: abgelöst durch aiup-flyway, aiup-jooq, aiup-spring-boot und aiup-vaadin und wird mit aiup-core 4.0.0 entfernt. Beim Wechsel behält ein Projekt seinen Code, seine Tests und seine Spezifikationen; der Migrationsleitfaden führt durch den Umstieg.
/flyway-migration
– Flyway Datenbankmigration erstellen
/implement
– Use Case mit Vaadin + jOOQ implementieren
/implement-hilla
– Use Case mit Hilla (React/TypeScript-Views) + jOOQ implementieren
/browserless-test
– Vaadin Browserless Unit-Tests erstellen
/hilla-test
– Vitest- und Spring-Boot-Tests für Hilla-Views und -Services erstellen
/playwright-test
– Playwright-Integrationstests für einen Use Case (UC-*) und End-to-End-Journey-Tests für einen Testfall (TC-*) erstellen
/coverage-check
– Use Case oder Testfall gegen seine Spezifikation prüfen und die Abdeckungsmatrix ausgeben
Kombiniertes Plugin für eine getrennte Client/Server-Architektur: ein Spring Boot + JPA Backend (flach oder hexagonal mit mehreren Modulen) mit einem Angular-Frontend.
Veraltet: abgelöst durch aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-angular und aiup-playwright und wird mit aiup-core 4.0.0 entfernt. Der Migrationsleitfaden führt ein bestehendes Projekt durch den Umstieg.
Ein besonderer Dank geht an Marc Affolter für den Beitrag dieses Plugins.
/flyway-migration
– Flyway Datenbankmigration erstellen
/implement
– Use Case mit Spring Boot + Angular implementieren
/spring-boot-test
– Spring Boot API-Tests erstellen
/vitest-test
– Vitest Komponententests für Angular erstellen
/playwright-test
– Playwright E2E-Tests erstellen
/coverage-check
– Use Case oder Testfall gegen seine Spezifikation prüfen und die Abdeckungsmatrix ausgeben
Kombiniertes Plugin für C# und Blazor auf .NET 10: EF Core Datenzugriff und Blazor-Komponenten, umgesetzt in einer Vertical Slice Architecture.
Es bleibt dauerhaft ein kombiniertes Plugin. Ein vertikaler Slice hält Handler und Datenzugriff eines Use Case zusammen, und horizontale Layer-Plugins würden sie auseinanderreissen.
Ein besonderer Dank geht an Carl J. Mosca für den Beitrag dieses Plugins.
/ef-migration
– EF Core Datenbankmigration erstellen
/implement
– Use Case mit C# + Blazor implementieren
/bunit-test
– bUnit Komponententests für Blazor erstellen
/dotnet-test
– Backend Unit- und Integrationstests erstellen
/playwright-test
– Playwright E2E-Tests erstellen
Kombiniertes Plugin für eine TypeScript-native Client/Server-Architektur: ein NestJS-Backend mit Drizzle ORM über PostgreSQL und ein Next.js App Router Frontend.
Veraltet: abgelöst durch aiup-drizzle, aiup-nestjs, aiup-nextjs und aiup-playwright und wird mit aiup-core 4.0.0 entfernt. Der Migrationsleitfaden führt ein bestehendes Projekt durch den Umstieg.
Ein besonderer Dank geht an Swift Ugandan für den Beitrag dieses Plugins.
/drizzle-migration
– Drizzle-Schema und SQL-Migration erstellen
/implement
– Use Case mit NestJS + Next.js implementieren
/nest-test
– NestJS Backend-Tests mit Vitest erstellen
/react-test
– Vitest Komponententests für Next.js erstellen
/playwright-test
– Playwright E2E-Tests erstellen
Starten Sie in Claude Code in wenigen Schritten; andere Agenten folgen weiter unten
Fügen Sie in Claude Code den Marketplace hinzu und installieren Sie aiup-core sowie ein Plugin pro Schicht Ihres Projekts. Dieses Beispiel ist eine Vaadin-Anwendung mit jOOQ:
Andere Stacks (siehe die häufigen Kombinationen):
aiup-vaadin weglassen.aiup-jpa, aiup-angular und aiup-playwright.aiup-drizzle, aiup-nestjs, aiup-nextjs und aiup-playwright.aiup-blazor-dotnet statt der Layer-Plugins.aiup-core. Die Methodik-Skills sind stack-agnostisch, und der Stack-Leitfaden zeigt, wie Sie ein Plugin für Ihren eigenen Stack bauen.Mehr über Plugin-Marktplätze erfahren Sie in der Claude Code Dokumentation.
Nach der Installation funktionieren Slash-Befehle direkt, zum Beispiel /requirements. Wenn zwei installierte Plugins denselben Befehlsnamen liefern, unterscheiden Sie mit der Namespaced-Form /plugin-name:command.
/stack schreibt die Stack-Datei, docs/architecture/stack.md: welcher Layer-Skill welche Schicht baut und testet, die Integrationsschicht pro Einstiegsschicht, den E2E-Umfang, die Modulstruktur sowie die Build- und Testbefehle.
docs/architecture.md) als Eingabe und verändert sie nie.Beginnen Sie mit den aiup-core-Befehlen für Anforderungen und Modellierung, dann implementieren und testen Sie jeden Use Case mit /use-case-implement und /use-case-test. Jeder Schritt baut auf dem vorherigen auf.
/next liest den Stand des Projekts und nennt den nächsten Befehl mit Begründung: ein fehlendes Dokument, eine blockierende Frage, ein Use Case, der auf das Review wartet, die Implementierung, die Tests, die Abnahme, das Benutzerhandbuch oder die Release Notes. Angefangene Arbeit kommt zuerst: Ein implementierter Use Case bekommt seine Tests, bevor der nächste gebaut wird./requirements, /entity-model und /use-case-spec stellen zuerst höchstens fünf Fragen, nur die, deren Antwort das Ergebnis verändert und für die es keinen vernünftigen Standard gibt. Alles andere entscheiden sie mit einem genannten Standard und führen es als Annahme auf.docs/open_questions.md. Ein Product Owner beantwortet die Frage dort mit /open-questions answer OQ-002, und /use-case-spec, /requirements oder /entity-model übernehmen die Antwort in die Spezifikation./use-case-implement und /use-case-test erneut aus: Sie gleichen den bestehenden Code und die bestehenden Tests mit dem geänderten Use Case ab, statt neue zu erzeugen. Für ein neues Feature, eine Änderung oder einen Bug gibt es keinen eigenen Befehl./business-process sie zu einem BPMN-Geschäftsprozess, und /test-case BP-001 leitet daraus je Pfad einen End-to-End-Testfall ab.docs/, es geht also nichts verloren. Eine lange Session, die ihren Kontext mehrmals komprimiert, verliert dagegen Details und wird langsam.Mit einem kombinierten Stack-Plugin treten dessen /implement und Test-Befehle an die Stelle von /use-case-implement und /use-case-test. Noch ist das ein Workflow Befehl für Befehl; die KI-Automatisierung des Prozesses ist in Entwicklung.
/spec-review prüft die Spezifikationen gegeneinander. Es berichtet nur: Es ändert nie eine Spezifikation und schlägt für jeden Befund den Befehl vor, der ihn behebt.
/spec-review report schreibt das als eigenständige HTML-Seite, docs/spec-report.html, zum Teilen oder als Build-Artefakt./use-case-coverage prüft einen implementierten Use Case (UC-*) gegen seine Spezifikation, /test-case-coverage eine Testfall-Journey (TC-*) gegen ihren Testfall. Beide liefern eine Abdeckungsmatrix: welche Schritte des Hauptszenarios, Alternativabläufe, Geschäftsregeln, Vorbedingungen und Nachbedingungen durch Code und Tests abgedeckt sind, was noch offen ist und wo Code oder Tests von der Spezifikation abgewichen sind.
/use-case-implement und /use-case-test erneut ausführen.Schichten: eines Use Case auslässt, ist nie eine Lücke.Die veralteten kombinierten Plugins aiup-vaadin-jooq und aiup-angular-jpa liefern dieselbe Prüfung als /coverage-check.
Agent Skills (SKILL.md) ist mittlerweile ein offener Standard, und jedes Plugin entspricht zusätzlich dem Agent-Plugins-Paketstandard (agent-plugins.org). Dieselben Skill-Dateien aus diesem Marketplace laufen nativ, mit automatischer Aktivierung über die Beschreibung, in OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI und OpenCode. Installieren Sie sie mit Tessl, laden Sie sie mit einem beliebigen Agent-Plugins-Client, oder klonen Sie das Repository, legen Sie die Skill-Ordner in das Skills-Verzeichnis Ihres Tools ab und konfigurieren Sie die MCP-Server.
Tessl ist ein agent-agnostischer Paketmanager für Skills: Er installiert versionierte Skills und trägt die MCP-Server in das richtige Verzeichnis des jeweils erkannten Coding-Agents ein. Alle Plugins sind in der Tessl-Registry unter ai-unified-process/ veröffentlicht, zum Beispiel ai-unified-process/aiup-core und die Layer-Plugins ai-unified-process/aiup-flyway, ai-unified-process/aiup-jooq, ai-unified-process/aiup-spring-boot und ai-unified-process/aiup-vaadin. Installieren Sie dieselbe Kombination wie in Claude Code:
Installierte Plugins landen in .tessl/plugins/ und werden in tessl.json versioniert, reproduzierbar im ganzen Team.
Jedes Plugin-Verzeichnis ist zugleich ein konformes Agent-Plugins-Paket: der offene, herstellerneutrale Plugin-Standard, dessen Steering Committee Vertreter von Amazon, Cursor, Microsoft, OpenAI und Vercel angehören. Jedes Plugin liefert die plugin.json- und mcp.json-Manifeste des Standards zusätzlich zu den Claude-Code-Manifesten mit.
Jeder Client, der Agent Plugins implementiert, kann ein Plugin direkt aus einem Checkout des Marketplace-Repositorys laden, inklusive Skills und MCP-Servern, ohne Konvertierung.
Klonen Sie das Marketplace-Repository, kopieren oder verlinken Sie die Skill-Ordner in das Skills-Verzeichnis Ihres Tools und übernehmen Sie die MCP-Server aus der .mcp.json des jeweiligen Plugins in die MCP-Konfiguration Ihres Tools.
Skills lösen Sie genauso aus wie in Claude Code: sagen Sie „schreibe Anforderungen" oder rufen Sie /requirements auf. Die erzeugten Dateien sind toolunabhängig identisch, sodass die Kette auch beim Mischen von Tools über die Schritte hinweg funktioniert.
Native SKILL.md-Unterstützung: Ablage in ~/.codex/skills/ oder .agents/skills/.
Native Agent Skills seit Cursor 2.4: Ablage im projektlokalen .cursor/skills/.
Versteht die /plugin-Marketplace-Befehle von Claude Code direkt: Plugins wie in Claude Code installieren, inklusive Skills und MCP.
Native SKILL.md-Unterstützung: Ablage in .gemini/skills/ oder ~/.gemini/skills/.
Native Skill-Unterstützung; durchsucht auch .claude/skills/ und .agents/skills/, sodass für Claude Code installierte Skills ohne Kopieren übernommen werden.
Ein separates IDE-Plugin für IntelliJ und Visual Studio Code, das Use-Case-Spezifikationen mit ihren Tests verknüpft, unabhängig von Claude Code
Klicken Sie auf das Gutter-Symbol einer mit @UseCase annotierten Testmethode, um zur passenden UC-XXX-*.md-Spezifikation zu springen, und vom Spec-Header zurück zum Test.
Markdown-Header und Geschäftsregel-Referenzen in Ihren Spezifikationen werden klickbar, sodass Anforderungen und Tests synchron bleiben.
In IntelliJ IDEA: Einstellungen → Plugins → Marketplace; in Visual Studio Code: Extensions-Ansicht öffnen. Suchen Sie nach "AI Unified Process Navigator" und klicken Sie auf Installieren. Claude Code wird nicht benötigt.
Open Source unter Apache License 2.0. Funktioniert mit IntelliJ IDEA und anderen JetBrains-IDEs sowie mit Visual Studio Code.
Workshops, Beratung und massgeschneiderte Einführungen des AI Unified Process. Vereinbaren Sie einen Termin, um zu besprechen, wie der AI Unified Process zu Ihrem Stack und Team passt.