The AI Unified Process (AIUP) has always separated the stack-independent specifications from their construction. In the old marketplace, construction lived in a combined stack plugin: one plugin bundled everything downstream of the specifications for one fixed combination of technologies.
aiup-core wrote the requirements, the entity model, the use cases, and the test cases. A project then installed exactly one stack plugin, and that plugin shipped a migration skill, /implement, one or two test skills, /playwright-test, and in two cases /coverage-check. The four stacks:
aiup-vaadin-jooq– Vaadin Flow or Hilla with jOOQ: /flyway-migration, /implement, /implement-hilla, /browserless-test, /hilla-test, /playwright-test, /coverage-checkaiup-angular-jpa– Angular with Spring Boot and JPA: /flyway-migration, /implement, /spring-boot-test, /vitest-test, /playwright-test, /coverage-checkaiup-blazor-dotnet– Blazor and EF Core on .NET 10: /ef-migration, /implement, /dotnet-test, /bunit-test, /playwright-testaiup-nestjs-nextjs– NestJS and Drizzle with Next.js: /drizzle-migration, /implement, /nest-test, /react-test, /playwright-testA project combines aiup-core with one plugin per technical layer. The combination is recorded in the stack file of the project, and six commands in aiup-core run the layer skills in order. aiup-core itself knows nothing about any technology.
| Layer | Builds | Plugin | Skills |
|---|---|---|---|
| Migration | Versioned schema changes from the entity model | aiup-flyway | /flyway-schema |
| Persistence | Queries, repositories, entity mapping, projections | aiup-jooq or aiup-jpa | /jooq-persistence, /jpa-persistence, each with a -test skill |
| Service | Business logic, transactions, business rules | aiup-spring-boot | /spring-service, /spring-service-test |
| API | Endpoints, DTOs, and error format for a separate client | aiup-spring-boot | /spring-rest, /spring-rest-test |
| UI | Views, forms, grids, navigation | aiup-vaadin or aiup-angular | /vaadin-flow-ui, /hilla-ui, /angular-ui, each with a -test skill |
| E2E | Browser tests of a use case or a test case journey | aiup-vaadin or aiup-playwright | /vaadin-e2e-test, /playwright-e2e-test |
The stack file records which layer skill builds and tests each layer. It always lives at docs/architecture/stack.md, one path that every skill reads. The stack file belongs to the AI Unified Process, not to your architecture documentation: whether the team writes arc42, C4, Kruchten's 4+1 views, a single docs/architecture.md, or nothing, the stack file sits next to it and looks the same. /stack reads those documents and the architecture decision records as input and never writes, moves, or indexes them.
/stack detects the stack of an existing project from pom.xml, package.json, and the source tree, asks what it cannot detect, and records which skill builds and tests each layer. A layer the project does not have is marked with a dash. Below the Layers table, an Integration layer table names, for each entry layer, the layer a use case is tested in, and with an end-to-end layer an E2E scope line records whether browser tests cover every use case offered through the UI or only the test case journeys. The file also holds the module layout, the API contract, the build and test commands, and the Markers table the coverage audit reads. It owns only the Layers and Markers sections and writes the other three only when their heading is missing or they still hold the template's placeholder, so what the team wrote by hand stays.
Migration– Flyway: flyway-schemaPersistence– jOOQ: jooq-persistence, jooq-persistence-testService– Spring Boot: spring-service, spring-service-testAPI– Spring REST: spring-rest, spring-rest-testUI–E2E–This is the Layers table of a REST API with Spring Boot and jOOQ: a project the old marketplace could not express. Its integration layer is the API.
The orchestration moved from the stack plugin into aiup-core. The commands are named use-case-<step> and test-case-<step>, next to /use-case-spec and /test-case, so they never collide with the /implement of a combined stack plugin, and old and new plugins can coexist in one agent host. The names are final: they stay when the combined stacks are gone.
/stack– Write or update the stack file/use-case-implement UC-001– Run the layer skills of the Skill column bottom-up: migration, persistence, service, API, UI/use-case-test UC-001– Run the test skills from the integration layer up/use-case-coverage UC-001– Audit code and tests against the specification with the markers from the stack file/test-case-implement TC-001– Automate a test case journey with the end-to-end test skill/test-case-coverage TC-001– Audit a journey test against its test case/use-case-implement and /use-case-test also accept layer names, so "/use-case-implement UC-001 api" builds only the API layer. And every layer skill still runs on its own: "/jooq-persistence UC-001" reads the same inputs and follows the same rules.
UI, API, and, for a use case no actor reaches through either, such as a scheduled job, Service are the entry layers: where an actor reaches the system. A use case can name the entry layers that offer it in an optional Layers line. Without the line, every entry layer of the project offers it. That is what makes a Vaadin Flow application with a REST API next to it expressible: an administration screen without an API says "Layers: UI", a partner interface without a screen says "Layers: API".
/use-case-implement builds only the named entry layers, plus the migration, persistence, and service the use case needs. /use-case-test tests in the topmost in-process layer the use case uses, so an API-only use case of a Vaadin Flow application is tested in the API layer. /use-case-coverage reports no gap for a layer the line leaves out. The line names entry points, never a technology; /use-case-spec writes it, and the German specification calls it Schichten.
The implementation runs in the order migration, persistence, service, API, UI. The tests run from the integration layer up and end with end-to-end, as far as the E2E scope in the stack file asks for it. Each layer skill ends with a Handover block naming the tables, record types, method signatures, or endpoints it created or changed. The next layer builds on exactly that contract and does not reinvent a DTO or a method the layer below already provides.
The stack file also names the integration layer, one row per entry layer the project has (UI, API, Service): the layer whose test skill runs in process against the real service and database. A use case is tested in the first row its Layers line names. In a Vaadin Flow application that is the UI, because its Browserless tests run the service and the repository for real. In a REST service, or behind an Angular client, it is the API. Behind a Hilla UI it is the service. /use-case-test runs the test skills from that layer up and writes no tests of its own for the layers below. The integration layer's tests cover the whole use case: the main success scenario, every alternative flow, every business rule with its allowed and its rejected case, and the postconditions read back from the persisted state.
A lower layer still gets tests in four cases: when it is a second entry layer of the use case, such as a REST API next to a Vaadin Flow or Hilla UI, which then tests its own contract (the main success scenario through its endpoint, each alternative flow's response, and the validation mapping) but not the business rules again; when a run names it, as in "/use-case-test UC-001 persistence"; when it already holds tests of the use case that need reconciling; or when the integration layer's skill reports a unit it cannot reach through its entry point. The coverage audit reads the same table, so a skipped layer is never reported as a gap. A stack file that still has a single integration layer line gets the table on the next /stack run; until then /use-case-test hands over to /stack.
What changed for a team that installs the plugins, and what the change buys.
| Combined stack plugin, until 2.x | Layer plugins, since 3.0.0 | |
|---|---|---|
| What you install | aiup-core plus exactly one stack plugin | aiup-core plus one plugin per layer |
| Combinations | Four fixed stacks | Any combination from the catalog, including a REST API without a UI, or a Vaadin UI with a REST API next to it |
| Where the layers are recorded | Hard-wired in the plugin | The stack file, docs/architecture/stack.md, written by /stack |
| Implementation | /implement of the stack plugin builds the whole slice | /use-case-implement in aiup-core runs the layer skills bottom-up with a handover between them |
| Tests | One test skill per tool: /browserless-test, /spring-boot-test, /vitest-test, /playwright-test | /use-case-test runs the test skills from the integration layer up, so a use case is tested once; each test skill still runs on its own |
| Coverage audit | /coverage-check, only in aiup-vaadin-jooq and aiup-angular-jpa | /use-case-coverage in aiup-core, for every combination |
| Shared rules | Copied into every plugin's /implement | Once, in /use-case-implement and /use-case-test |
| Markers for the audit | A fixed list inside each plugin's agent | The Markers table in the stack file, maintained by the layer skills |
| Adding a technology | A new stack plugin with five or more skills | One layer plugin with one or two skills; its references/layer.md lets /stack discover it without a core release. A team's own skill counts too, with or without a layer.md |
| Version | Each plugin on its own version | aiup-core and the layer plugins share one major version; the layer plugins need aiup-core 3.0.0 or later |
Install aiup-core in every project, then one plugin per layer the project has. Use either layer plugins or one combined stack plugin, never both: the combined plugins do not read the stack file.
REST API, Spring Boot, jOOQ– aiup-flyway, aiup-jooq, aiup-spring-boot. Integration layer: APIREST API, Spring Boot, JPA– aiup-flyway, aiup-jpa, aiup-spring-boot. Integration layer: APIVaadin Flow or Hilla, jOOQ– aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadin. Integration layer: UI with Flow, service with HillaVaadin Flow and a REST API, jOOQ– aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadin. Integration layer: UI, and the API for use cases whose Layers line names only the API. For a use case offered through both, the API tests its own contractAngular, Spring Boot, JPA– aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-angular, aiup-playwright. Integration layer: APIA server-side UI such as Vaadin Flow calls the service layer directly and needs no API layer; in a project without a service layer it may call the repositories, as long as Flow is the only entry layer; an API layer next to it serves other clients, such as a mobile app or a partner system. A client-side UI such as Angular always needs one: a use case offered through an Angular UI is also built in the API layer and tested there. Hilla's endpoint belongs to /hilla-ui, not to a separate API layer. When no layer plugin covers a technology you use, /stack records the technology with a dash in the Skill column, and /use-case-implement builds that layer from its own knowledge and the project's conventions.
The example is a REST API with Spring Boot and jOOQ. Add aiup-vaadin for a Vaadin UI, or aiup-angular and aiup-playwright for an Angular UI.
Tessl installs the skills for Codex, Cursor, GitHub Copilot, Gemini CLI, and OpenCode and pins the versions. See other AI coding tools.
Once the specifications are approved, one use case goes through four commands. The first one runs once per project.
Once per project, and again when a layer changes. In an existing project the skill detects the stack and asks only where two technologies fit, for example JPA and jOOQ both on the classpath. In a new project it asks for a technology per layer, and offers a dash for a layer the project does not need. It writes the stack file to docs/architecture/stack.md, then checks that every skill it recorded is installed and names the missing plugins.
Reads the use case, exactly the requirements its Requirements line links, the entity model, the glossary, and the stack file. It checks the Status line, collects the gaps of all layers so you answer once, then states what will run and what the use case's Layers line leaves out, and runs the layer skills bottom-up, passing each handover to the next layer. It writes no tests and ends with an Open questions list for the specification.
Runs the test skills from the integration layer up. That layer's tests exercise the whole use case against the real service and database: every business rule with its allowed and its rejected case, every alternative flow, and the postconditions read back from the persisted state. A UI that mocks its backend, such as Hilla or Angular, tests only what the UI decides and that a rejection reaches the actor; the end-to-end layer tests the scenarios an actor sees in the browser. Existing tests are updated, not duplicated. A test that fails because the code disagrees with the specification stays failing and is reported; which side is wrong is your call.
A read-only sub-agent maps every step, alternative flow, business rule, precondition, postcondition, and linked NFR or constraint onto the code and the tests behind it, using the markers from the stack file. It reports gaps and drift and suggests the next value for the Status line. It never edits a file; closing a gap is /use-case-implement or /use-case-test again.
A project on aiup-vaadin-jooq or aiup-angular-jpa keeps its code, its tests, and its documents. The plugins, the command names, and the location of the UseCase annotation change. The migration guide in the marketplace has the full walkthrough.
Remove the combined plugin through your agent's plugin management, update aiup-core to 3.0.0 or later, and install the layer plugins of your stack.
aiup-vaadin-jooq– becomes aiup-flyway, aiup-jooq, aiup-spring-boot, aiup-vaadinaiup-angular-jpa– becomes aiup-flyway, aiup-jpa, aiup-spring-boot, aiup-angular, aiup-playwrightThe skill detects Flyway, jOOQ or JPA, Spring Boot, and the UI framework from the build files and the source tree, records the module layout, the commands, and the integration layer, and writes the stack file to docs/architecture/stack.md. Architecture documentation the project already has, a docs/architecture.md, arc42, or C4, is read as input and stays where it is. Nothing in the code changes. The Markers table fills up the next time each layer skill runs.
The combined plugins created the annotation under src/main/java. The layer test skills look for it in the test sources of the module under test and would create a second copy there. Move the file to src/test/java before the first /use-case-test and keep its package, so no import changes. The layer test skills add the attribute requirements, which names the NFR and constraint ids a test asserts, to an annotation that lacks it. A hexagonal project gets one copy per module that holds use case tests.
/flyway-migration– /flyway-schema, normally run by /use-case-implement/implement– /use-case-implement/implement-hilla– /use-case-implement, with hilla-ui in the UI row of the Layers table/browserless-test– /vaadin-flow-ui-test, the integration layer of a Vaadin Flow application, run by /use-case-test/hilla-test– /hilla-ui-test for the views, /spring-service-test for the service behind them/spring-boot-test– /spring-rest-test as the integration layer behind Angular; /spring-service-test and /jpa-persistence-test only when a run names them or a unit is out of the API's reach/vitest-test– /angular-ui-test/playwright-test– /vaadin-e2e-test or /playwright-e2e-test, also as /test-case-implement TC-001/coverage-check– /use-case-coverage UC-XXX, /test-case-coverage TC-XXX/karibu-test– Not carried over. Browserless Testing supersedes Karibu; existing Karibu tests keep runningThe next time a use case changes, /use-case-implement finds the existing views, services, and repositories by the names the specification implies and by their UC-XXX references, and changes them in place. Code the combined plugin wrote is reconciled exactly like code the layer plugins wrote. The service layer, which the old /implement built as part of the slice, now belongs to /spring-service and is reconciled by it.
The layer plugins change how construction is organised, not what it reads or how it is traced. Everything the stack guide describes still holds.
The use case, exactly the requirements it links, the entity model, the glossary, and the architecture decision records. The boundary between aiup-core and construction is still the set of files under docs/.
A UC-XXX BR-YYY comment above the code that enforces a business rule, and @UseCase or a describe block naming the use case, scenario, and rules in every test.
A new feature, a change, and a bug all end in a changed use case. The skills find the existing code and change it in place; a second view for the same use case is still the failure mode they exist to prevent.
Expected values come from the specification, never from what the code returns. A disagreement is reported, not papered over by weakening an assertion.
No skill edits the Status line of a use case. The coverage audit suggests the next value; a person sets it.
Requirement to use case to business rule to code and test, and business process to test case to journey test, in the same identifiers as before.
Install aiup-core 3.0.0 and the layer plugins of your stack, run /stack, and the next use case goes through /use-case-implement. AI Unified Process Studio writes the specifications these commands read; request an invitation, or get in touch if you want help choosing the combination for your architecture.