The AI Unified Process (AIUP) keeps requirements at the center. Everything upstream of code is the same for every team; everything that depends on a framework, a persistence layer, or a test tool belongs to a stack plugin.
aiup-core writes the requirements catalog, the entity model, the use case diagram, the use case specifications, and the end-to-end test cases. None of these mention a framework. Its /spec-review checks them against each other before anything is implemented. They are the input to your stack plugin, and your plugin must never rewrite them.
A stack plugin encodes your architecture decisions: module layout, data access, UI technology, test frameworks, and the documentation servers the agent should consult. A project installs aiup-core plus exactly one stack plugin, because stacks share command names such as /implement.
Use the existing plugins in the marketplace repository as reference implementations. aiup-vaadin-jooq is the most complete one; aiup-angular-jpa was built by a practitioner whose team needed Angular and JPA, and aiup-blazor-dotnet and aiup-nestjs-nextjs followed the same way.
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-testThe contract defines roles, not a fixed list of file names. /implement and /playwright-test keep their names in every stack, because the other skills, the documentation, and AI Unified Studio hand off to them. The migration and test skills are named after the tool they use.
Required. Named after your migration tool: /flyway-migration, /ef-migration, /drizzle-migration.
Reads the entity model and the migrations that already exist, then writes the next versioned migration: tables, sequences or identity columns, constraints, and foreign keys, with referenced tables created first. It follows the naming the data access layer expects.
Required. Always called /implement.
Reads one use case specification and the entity model and writes the complete slice for it: UI, service or endpoint, data access, and the types passed between them. It follows the patterns already present in the project, compiles the result, writes no tests, and ends by naming the next command, for example "Next: /browserless-test UC-001".
Required. Named after the test tool: /browserless-test, /spring-boot-test, /vitest-test, /dotnet-test, /nest-test.
Writes one test class or test file per use case and covers the specification, not the code: one test for the main success scenario, one per alternative flow (A1, A2, …), and one per business rule (BR-XXX). A stack with a separate frontend may ship one skill per side, as aiup-angular-jpa and aiup-nestjs-nextjs do.
Required. Always called /playwright-test.
With a use case ID it drives the running application through that use case's scenarios. With a test case ID it reads the test case and every use case in its Flow table and writes one journey test: one step per Flow row, the concrete test data from the test case, and cleanup derived from its Postconditions. Test case support is strongly recommended; it is what turns a business process into an automated regression test.
Recommended. /coverage-check plus a read-only agent.
Maps every main success scenario step, alternative flow, business rule, precondition, and postcondition onto the code and tests behind it, reports gaps and drift, and suggests the next value for the specification's Status line. It is the stack-side counterpart of /spec-review in aiup-core: that one checks specifications against each other, this one checks code and tests against a specification. The agent gets only Read, Grep, and Glob: it reports, it never edits. Today only aiup-vaadin-jooq ships one, so the agent in that plugin is the template to copy.
A stack plugin reads the documents aiup-core writes, in the places aiup-core writes them. Do not invent a second format; the requirements-driven chain only works when every stack reads the same files.
docs/requirements.mdFunctional requirements (FR-XXX), non-functional requirements, and constraintsdocs/entity_model.mdEntities, attributes, data types, validation rules, and relationshipsdocs/use_cases/UC-*.mdOne specification per use casedocs/test_cases/TC-*.mdEnd-to-end journeys that chain several use casesUI mockups, OpenAPI documents, and schemas are referenced from the use case that needs them. Follow those references; there is no separate folder to scan.
Every generated test names the use case, scenario, and business rules it verifies. The AI Unified Process Navigator shows these links as gutter icons in IntelliJ and VS Code, AI Unified Studio builds its traceability view from them, and the coverage audit uses them to find the tests. A test without a marker counts as a gap.
The test skill creates the annotation if the project does not have it yet. The tools resolve it by its short name, so the package is up to you.
Use it on test methods only. The values must match the headings in the specification exactly:
Test frameworks without annotations carry the same information in the test names and tags:
For another language, use its native equivalent (an attribute, a trait, a tag) with the same three fields: use case ID, scenario, and business rules.
UC001ManagePersonsTestUnit or integration test class for one use case (Java, C#)UC001ManagePersonsITBrowser test for one use caseUC-001-manage-persons.spec.tsTest file for one use case (JavaScript, TypeScript)TC001CustomerOnboardingITJourney test with a TC-001 display name and one "Step n" comment per Flow rowProduction code has no required marker, but a short class comment naming the use case and a BR-XXX comment next to the code enforcing a business rule make the coverage audit and the next reconciliation far more reliable.
A new feature, a change request, and a bug all end in the same place: a changed use case specification. There is no separate command for any of them. The user edits the specification and re-runs /implement and the test commands, so every implement and test skill must detect existing code and change it in place.
A stack plugin is a folder of skills with a manifest. Start by copying the existing stack plugin closest to yours and replace the technology, not the structure.
Each SKILL.md starts with a name and a description that lists the phrases that should trigger it ("implement a use case", "write a migration", the name of your framework). The body follows the same sections as the existing skills: instructions, an "If an implementation already exists" section with the reconcile rules above, a DO NOT list, the workflow, and the hand-off to the next command. A skill may link only to files inside its own folder; put examples and reference code there.
Model training data lags behind framework releases. Declare MCP servers for your framework's documentation in .mcp.json, plus the Playwright server for browser tests, and tell the skills to consult them before writing code against an API.
To run in Codex CLI, Cursor, GitHub Copilot, Gemini CLI, and OpenCode as well, add the Agent Plugins manifest (plugin.json and mcp.json at the plugin root) and the Tessl manifest, and keep their versions in step with .claude-plugin/plugin.json. See other AI coding tools.
Open a pull request against the marketplace repository so every team on your stack can install it with one command. Keeping it in your own repository works too; a Claude Code marketplace is just a Git repository with a marketplace.json.
Migration, /implement, unit or integration tests, and /playwright-test exist and hand off to each other.
The skills read docs/entity_model.md, docs/use_cases/, and docs/test_cases/ and never rewrite them.
Each test names its use case ID, scenario, and business rules, matching the specification's headings exactly.
Running /implement twice on an unchanged specification changes nothing and creates no new files.
After editing one alternative flow, /implement and the test skill change only the code and tests for that flow.
/playwright-test TC-001 produces one journey test with one step per Flow row.
AI Unified Studio writes the specifications your stack plugin reads. Request an invitation, or get in touch if you want help designing a plugin for your architecture.