Skip to content

AI-Unified-Process/marketplace

BranchesTags

Repository files navigation

AI Unified Process Marketplace

A collection of Claude Code plugins that automate the AI Unified Process (AIUP) — a structured workflow for taking a software project from raw vision to fully implemented, tested code, with requirements at the center at every step.

What is the AI Unified Process?

AI Unified Process is a disciplined AI-assisted development methodology where every project starts with a written vision, proceeds through requirements, an entity model, and use case specifications, and only then enters implementation. Nothing gets built without a use case. Nothing reaches production without tests traceable to requirements.

This prevents the common failure mode of AI-assisted development: jumping straight to code from a vague prompt, producing something that half-works and can't be maintained.

The methodology is based on the phases of the Rational Unified Process — Inception, Elaboration, Construction, Transition — but adapted for AI-driven workflows.

AIUP Workflow

Inception          Elaboration                          Construction
─────────────────  ──────────────────────────────────   ────────────────────────────────────────────────
/requirements  →  /entity-model  →  /use-case-diagram  →  /use-case-spec  →  /flyway-migration
                                                                          ↘  /implement
                                                                          ↘  /browserless-test
                                                                          ↘  /playwright-test

For an Angular/JPA project, the inception and elaboration parts look the same, as they are part of the aiup- core plugin. The construction, however, is optimized for tech stack SpringBoot with JPA and Angular in frontend. It tests the frontend with Angular vitest unittests, the backend with spring-boot integrations tests and the whole app with playwright e2e tests. Further it takes existing backend architecture, a hexagonal multi-module Maven reactor rather than a single flat module into consideration.

Inception          Elaboration                          Construction
─────────────────  ──────────────────────────────────   ────────────────────────────────────────────────
/requirements  →  /entity-model  →  /use-case-diagram  →  /use-case-spec  →  /flyway-migration
                                                                          ↘  /implement
                                                                          ↘  /spring-boot-test
                                                                          ↘  /vitest-test
                                                                          ↘  /playwright-test

Each skill picks up where the previous one left off using the files produced along the way (docs/vision.md, docs/requirements.md, docs/entity_model.md, docs/use_cases.puml, docs/use_cases/UC-*.md, docs/test_cases/TC-*.md). At any point you can inspect or manually edit these files before continuing.

Inheriting a legacy codebase? Start with /reverse-engineer — it walks the existing code, configuration, and schema and produces the same docs/use_cases.puml, docs/use_cases/UC-*.md, and docs/entity_model.md artifacts the forward workflow would have produced, giving you a documented baseline to work from.

Inception Elaboration Construction Transition
aiup-core /requirements /entity-model
/use-case-diagram		 /use-case-spec
/test-case
aiup-vaadin-jooq /flyway-migration
/implement
/browserless-test
/playwright-test
aiup-angular-jpa /flyway-migration
/implement
/spring-boot-test
/vitest-test
/playwright-test

Prerequisites

  • Claude Code installed and running in your project
  • A docs/vision.md file at the root of your project describing the product vision, target users, and high-level goals (the /requirements skill reads this file to derive your requirements catalog — the richer it is, the better the results)
  • For the Vaadin/jOOQ plugin: a Maven or Gradle project with Vaadin and jOOQ already on the classpath
  • For the Angular/JPA plugin: a Maven or Gradle backend project with Spring Boot, Spring Data JPA, and Flyway (flat single module or a hexagonal domain/business/postgres/api/app-style multi-module layout), plus a separate Angular (standalone components) frontend project

Installation

/plugin marketplace add ai-unified-process/marketplace
/plugin install aiup-core
/plugin install aiup-vaadin-jooq        # for a Vaadin + jOOQ project
/plugin install aiup-angular-jpa        # for an Angular + JPA project

Install only aiup-core if you are using a different tech stack — the methodology skills are stack-agnostic. Install exactly one stack plugin alongside it, matching your project.

Verify installation

Start Claude Code in your project and run:

/requirements

If Claude begins reading docs/vision.md and proposing a requirements catalog, the skills are installed correctly.

Using AIUP with other AI coding tools

The AI Unified Process is a methodology, not a Claude-only product. Agent Skills (SKILL.md) is now an open standard, and the same skill folders in this marketplace work natively — with auto-triggering by description — in OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, and OpenCode. Pair them with the MCP server configs and the whole workflow runs unchanged.

Install via Tessl (any agent)

Tessl is an agent-agnostic package manager and registry for skills: it installs versioned skills and wires the MCP servers into the correct per-agent directory for whichever coding agent it detects. All plugins are published to the Tessl registry as aiup/aiup-core, aiup/aiup-vaadin-jooq, and aiup/aiup-angular-jpa, so this is the simplest way to adopt the workflow outside Claude Code — no manual cloning or per-tool MCP translation.

# one-time: configure your agent(s) — creates a tessl.json manifest at the repo root
tessl init --agent claude-code          # or: cursor, gemini, codex, copilot, copilot-vscode, agents
                                        # (repeat --agent to set up several at once)

# install the plugins from the registry (latest, or pin @version)
tessl install aiup/aiup-core
tessl install aiup/aiup-vaadin-jooq     # for a Vaadin + jOOQ project
tessl install aiup/aiup-angular-jpa     # for an Angular + JPA project

Installed plugins land in .tessl/plugins/ and are tracked in tessl.json, so versions are pinned and reproducible across your team. New versions are published automatically on every change by .github/workflows/publish-tessl.yml, so tessl install always resolves the latest release.

What transfers across agents:

  • Skills and methodology — fully portable; every supported agent auto-triggers them by their description.
  • MCP servers — Tessl wires them into any agent that supports MCP. Most aiup-vaadin-jooq servers are HTTP (fine on the agents listed above); a stdio-only client needs an HTTP↔stdio bridge (see Caveats).
  • Slash-command routing — the dispatcher behavior (/implement → stack-specific skill) is a Claude Code idiom. Other agents read the same Markdown but may not honor /-routing identically — invoke skills by intent instead (say "implement UC-001" rather than relying on the dispatcher).

Portability at a glance

Component Portable? Notes
tessl install aiup/… Yes Works on Claude Code, Cursor, Gemini, Codex, and Copilot — installs skills + MCP
MCP servers (aiup-*/.mcp.json) Yes Standard MCP — reformat the config per host
SKILL.md skill folders (aiup-*/skills/*/) Yes Native support in Codex CLI, Cursor, Copilot, Gemini CLI, and OpenCode
Auto-triggering by description Yes All tools above match user intent against the YAML frontmatter description
Workflow methodology (vision → requirements → … → tests) Yes The whole point — tool-agnostic
/plugin marketplace add … install Partial Works in Claude Code and GitHub Copilot; elsewhere use Tessl or clone this repo

Manual adoption recipe (without Tessl)

Prefer not to use Tessl? You can wire the skills in by hand:

  1. git clone https://github.com/ai-unified-process/marketplace.git next to your project (or add as a submodule).
  2. Make the skill folders visible to your tool — either copy aiup-core/skills/*/ and aiup-vaadin-jooq/skills/*/ into your tool's skills directory, or symlink them (e.g. ln -s /path/to/marketplace/aiup-core/skills/requirements ~/.codex/skills/requirements).
  3. Configure the MCP servers from aiup-core/.mcp.json and aiup-vaadin-jooq/.mcp.json in your tool's MCP config file.
  4. Trigger skills the same way you would in Claude Code — say "write requirements" or invoke /requirements. The tool matches your prompt against each skill's description and loads the matching SKILL.md. File outputs (docs/requirements.md, docs/entity_model.md, docs/use_cases.puml, docs/use_cases/UC-*.md) are identical regardless of tool, so the chain composes even if you mix tools across steps.

OpenAI Codex CLI

  • Skills: drop folders into ~/.codex/skills/ (user-global, default $CODEX_HOME/skills) or repo-local .agents/skills/. Codex matches user prompts against each skill's description automatically; toggle per skill with allow_implicit_invocation.
  • MCP: ~/.codex/config.toml under [mcp_servers.<name>] blocks. Translate aiup-vaadin-jooq/.mcp.json like this:
[mcp_servers.Vaadin]
url = "https://mcp.vaadin.com/docs"

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

See the Codex skills docs and the Codex config reference for the latest details.

Cursor

  • Skills: drop folders into project-local .cursor/skills/ (Cursor 2.4+). Cursor matches against each skill's description automatically. Note: there is no global skills directory yet — copy or symlink the marketplace skills into each project.
  • MCP: project-level .cursor/mcp.json or global ~/.cursor/mcp.json — uses mcpServers with the same shape as Claude's .mcp.json (url for HTTP servers, command / args for stdio). Drop in the contents of aiup-vaadin-jooq/.mcp.json directly.

GitHub Copilot

  • Plugin marketplace: Copilot understands Claude Code's marketplace commands directly, so you can install the plugins the same way as in Claude Code — no manual skill copying or MCP translation:

    /plugin marketplace add ai-unified-process/marketplace
/plugin install aiup-core
/plugin install aiup-vaadin-jooq        # or: aiup-angular-jpa

    This pulls in the skills and the MCP server configs from each plugin's .mcp.json.

  • Skills (manual alternative): Copilot reads from .github/skills/, .claude/skills/, and .agents/skills/ — pick one. Available in Copilot for VS Code, Visual Studio 2026, and the cloud agent.

  • MCP (manual alternative): workspace-level .vscode/mcp.json (commit it for your team), or user-level via MCP: Open User Configuration. Use "type": "http" for remote servers and "command" / "args" for stdio.

// .vscode/mcp.json
{
  "servers": {
    "Vaadin": { "type": "http", "url": "https://mcp.vaadin.com/docs" },
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
  }
}

Gemini CLI

  • Skills: drop folders into .gemini/skills/ (project) or ~/.gemini/skills/ (global). Gemini CLI matches prompts against each skill's description automatically.
  • MCP: ~/.gemini/settings.json mcpServers object — same shape as Claude's .mcp.json, so it is a near-direct copy.

OpenCode

  • Skills: drop folders into project-local .opencode/skills/ or global ~/.config/opencode/skills/. OpenCode also scans .claude/skills/ and .agents/skills/ (project and home directory), so skills already installed for Claude Code — or via Tessl with --agent claude-code or --agent agents — are picked up without copying. Skills are loaded on demand through OpenCode's built-in skill tool, matched against each skill's description; access can be restricted per skill with permission.skill patterns in opencode.json.
  • MCP: opencode.json at the project root (or ~/.config/opencode/opencode.json globally) under the "mcp" key — use "type": "remote" with url for HTTP servers and "type": "local" with a command array for stdio. Translate aiup-vaadin-jooq/.mcp.json like this:
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "Vaadin": { "type": "remote", "url": "https://mcp.vaadin.com/docs" },
    "playwright": { "type": "local", "command": ["npx", "@playwright/mcp@latest"] }
  }
}

See the OpenCode skills docs and the OpenCode MCP docs for the latest details.

Caveats

  • Argument passing (/use-case-spec UC-001) works everywhere but the syntax varies — Codex, Gemini CLI, and Cursor accept positional arguments after the skill name; in Copilot, pass the ID inline in the chat message after invoking the skill; in OpenCode, skills are not slash commands — state the ID in your prompt ("specify use case UC-001") and the agent loads the matching skill itself.
  • HTTP MCP servers: most aiup-vaadin-jooq servers are HTTP. Every tool listed above supports HTTP MCP. If you use a client that is stdio-only, you need an HTTP-to-stdio MCP bridge.
  • Cursor has no global skills directory — copy or symlink the marketplace skills into each project's .cursor/skills/.
  • Methodology stays the same: the file artifacts (docs/*.md, docs/use_cases/UC-*.md, Flyway migrations) are the contract between steps. As long as a step produces the right file, the next step works regardless of which tool ran the previous one.

How to use?

Here is a complete end-to-end example of building a hotel reservation system.

Step 1 — Generate the requirements catalog

/requirements

Claude reads docs/vision.md, identifies functional requirements (as user stories), non-functional requirements ( measurable quality attributes), and constraints, then writes them into docs/requirements.md as three separate tables. Every requirement gets a stable ID (FR-001, NFR-001, CON-001) and a status. Review the catalog before continuing.

Step 2 — Design the entity model

/entity-model

Claude reads docs/requirements.md, identifies the domain entities and their relationships, then writes docs/entity_model.md with a Mermaid ER diagram and one attribute table per entity (data type, length/precision, validation rules). Approve the model before moving to use cases.

Step 3 — Draw the use case diagram

/use-case-diagram

Claude reads docs/requirements.md, identifies actors and use cases, then writes a PlantUML diagram at docs/use_cases.puml. Each use case gets a stable ID (UC-001, UC-002, …) that traces back to one or more functional requirements.

Step 4 — Specify the use cases

/use-case-spec UC-001
/use-case-spec UC-001 UC-002 UC-003     # multiple at once

Claude writes a detailed specification per use case into docs/use_cases/ covering actors, preconditions, the main success scenario as numbered steps, alternative flows for error conditions, postconditions, and business rules. Each spec is a single document — Claude will not bundle multiple use cases together.

Step 5 — Create the database migrations

/flyway-migration

Claude reads docs/entity_model.md and writes versioned Flyway migrations (V001__create_*.sql, V002__…) into src/main/resources/db/migration. Primary keys use sequences (no auto-increment), foreign keys and check constraints are derived from the entity model. Run mvn flyway:migrate to apply.

Step 6 — Implement the use case

/implement UC-001

Claude reads the use case spec, the entity model, and existing code to learn your conventions, then implements the data access layer with jOOQ and the UI with Vaadin. It compiles after each layer and stops on errors. It does not write tests — those have dedicated skills.

Step 7 — Write Browserless unit tests

/browserless-test UC-001

Claude generates server-side Vaadin tests using the official Vaadin Browserless framework (com.vaadin:browserless-test-junit6) — no browser required. Tests cover navigation, component interactions, form validation, grid operations, and notifications. Test data is seeded via Flyway migrations under src/test/resources/db/migration; transaction boundaries are preserved (no @Transactional on tests).

Browserless Testing is free and open source under Apache 2.0 since Vaadin 25.1. It is the official successor to UI Unit Testing (formerly part of the commercial TestBench) and replaces the community Karibu Testing library as the recommended server-side testing approach. The legacy /karibu-test skill is still installed for existing projects but is no longer recommended for new code — use /browserless-test.

Step 8 — Write Playwright integration tests

/playwright-test UC-001     # use case test — integration tests for one view
/playwright-test TC-001     # test case journey — one end-to-end flow across views

Claude generates browser-based tests against the running application (default: http://localhost:8080) using the Drama Finder library for type-safe, accessibility-first element wrappers. Tests are written black-box — they do not look at the implementation — and never use raw Playwright locators or Thread.sleep().

The skill dispatches on the argument: a UC-* ID produces integration tests for a single view derived from the use case specification, while a TC-* ID reads a test case document from docs/test_cases/TC-*.md (a user journey chaining several use cases, created with /test-case) and produces one journey test class walking the whole flow. Test classes are named after the artifact: UC-001 → UC001CreateReservationIT, TC-001 → TC001CustomerOnboardingIT.

Skills Reference

/requirements — Requirements Catalog (plugin-agnostic)

Purpose: Turns a docs/vision.md document into a structured docs/requirements.md catalog with functional requirements, non-functional requirements, and constraints.

Usage:

/requirements

What it does:

  1. Reads docs/vision.md to understand product mission, users, and goals
  2. Extracts functional requirements as user stories (As a [role], I want [goal] so that [benefit]) with stable IDs ( FR-001, FR-002, …), priority, and status
  3. Extracts non-functional requirements as measurable quality attributes with category (Performance, Security, Availability, …), priority, and status
  4. Extracts constraints (technical, regulatory, business) with stable IDs (CON-001, CON-002, …)
  5. Writes all three as separate tables in docs/requirements.md — never mixing requirement types in one table

Input: docs/vision.md Output: docs/requirements.md Plugin: aiup-core

/entity-model — Entity Model (plugin-agnostic)

Purpose: Designs the domain entity model with a Mermaid ER diagram and per-entity attribute tables.

Usage:

/entity-model

What it does:

  1. Reads docs/requirements.md to identify the domain entities implied by the user stories
  2. Draws a Mermaid erDiagram showing entities and their relationships (cardinality, role names) — without listing attributes inside the diagram
  3. Produces one attribute table per entity with columns for attribute name, description, data type, length/precision, and validation rules (Primary Key, Sequence, NOT NULL, UNIQUE, foreign keys, check constraints)
  4. Writes the result to docs/entity_model.md

Input: docs/requirements.md Output: docs/entity_model.md Plugin: aiup-core

/use-case-diagram — Use Case Diagram (plugin-agnostic)

Purpose: Generates a PlantUML use case diagram showing actors, use cases, and their relationships derived from the requirements catalog.

Usage:

/use-case-diagram

What it does:

  1. Reads docs/requirements.md to identify actors and the use cases they participate in
  2. Assigns stable IDs (UC-001, UC-002, …), each tracing to at least one functional requirement
  3. Writes a .puml file at docs/use_cases.puml using left to right direction and a rectangle "System Name" boundary
  4. Uses standard PlantUML syntax only — no implementation details in use case names

Input: docs/requirements.md Output: docs/use_cases.puml Plugin: aiup-core

/use-case-spec — Use Case Specification (plugin-agnostic)

Purpose: Writes detailed specifications for one or more use cases, each as a separate document under docs/use_cases/.

Usage:

/use-case-spec UC-001
/use-case-spec UC-001 UC-002 UC-003     # multiple use cases at once

What it does:

  1. Reads docs/use_cases.puml and docs/requirements.md to scope the use case
  2. Writes one document per use case under docs/use_cases/ using a fixed template covering: Overview (ID, name, primary actor, goal, status), Preconditions, Main Success Scenario (numbered steps), Alternative Flows (for error conditions), Postconditions, and Business Rules
  3. Keeps flow steps free of implementation details
  4. Refuses to bundle multiple use cases into a single document

Input: Use case ID(s) as argument Output: docs/use_cases/UC-XXX-*.md (one file per use case) Plugin: aiup-core

/test-case — End-to-End Test Case Document (plugin-agnostic)

Purpose: Writes an end-to-end test case document (TC-*.md) that chains several use cases into one user journey — the input that /playwright-test TC-XXX automates as a journey test.

Usage:

/test-case UC-001 UC-004     # journey chaining the listed use cases

What it does:

  1. Reads the specification of every listed use case from docs/use_cases/ (and refuses to chain unspecified ones)
  2. Assigns the next free TC-XXX ID and names the file after the journey's goal (e.g. docs/test_cases/TC-001-customer-onboarding.md)
  3. Writes the document with a fixed template: Overview (ID, Goal, Priority, Status), Roles, Preconditions (each naming its seeded data source), a Flow table (Step | Name | Description | Test Data | Use Case), Validation, and Postconditions (the data the journey leaves behind — the automated test's cleanup contract)
  4. Orders the Flow as the business journey, inserts verification steps between actions, links each action step to its use case spec, and uses literal test data values so the document is executable
  5. Keeps per-use-case detail out — field-level validations belong to the use case tests; the journey and its end state are the subject

Input: Use case IDs as arguments Output: docs/test_cases/TC-XXX-*.md (one journey per file) Plugin: aiup-core

/reverse-engineer — Reverse Engineer Existing Project (plugin-agnostic)

Purpose: Recovers AIUP artifacts (use case diagram, per-use-case specifications, entity model) from an existing codebase so legacy projects can join the AIUP workflow without rewriting documentation by hand.

Usage:

/reverse-engineer

What it does:

  1. Detects the stack and locates entry points (controllers, routes, view classes), the data layer (ORM models or schema migrations), and authentication/authorization configuration
  2. Identifies actors from role/authority definitions, authentication boundaries, and external system integrations
  3. Groups entry points by user goal — not one use case per HTTP endpoint — and assigns stable IDs (UC-001, UC-002, …)
  4. Writes a PlantUML use case diagram, one specification document per use case, and an entity model with a Mermaid ER diagram, all in the exact formats produced by /use-case-diagram, /use-case-spec, and /entity-model
  5. Cross-validates that the three documents agree (every actor has a spec, every UC ID has a file, every entity referenced in a spec exists in the model)
  6. Reports gaps honestly — endpoints it couldn't classify, use cases where the success scenario was hard to recover

Input: Existing source tree Output: docs/use_cases.puml, docs/use_cases/UC-XXX-*.md, docs/entity_model.md Plugin: aiup-core

/flyway-migration — Flyway Database Migrations (in aiup-vaadin-jooq)

Purpose: Generates versioned Flyway migration scripts (V*.sql) that create the schema described in docs/entity_model.md.

Usage:

/flyway-migration

What it does:

  1. Reads docs/entity_model.md and translates each entity into a CREATE TABLE statement
  2. Creates a CREATE SEQUENCE for every primary key (no auto-increment)
  3. Adds NOT NULL, UNIQUE, CHECK, and foreign key constraints from the entity model's validation rules
  4. Names files using the Flyway convention V001__create_<table>_table.sql, V002__…
  5. Writes scripts to src/main/resources/db/migration
  6. Will not drop existing tables without explicit confirmation

Input: docs/entity_model.md Output: src/main/resources/db/migration/V*.sql Plugin: aiup-vaadin-jooq

/implement — Use Case Implementation

Purpose: Implements a use case end-to-end using Vaadin for the UI layer and jOOQ for the data access layer.

Usage:

/implement UC-001

What it does:

  1. Reads the use case specification from docs/use_cases/ and the entity model from docs/entity_model.md
  2. Reads existing code first to match conventions before creating new files
  3. Implements the data access layer using jOOQ — verifies it compiles before continuing
  4. Implements the Vaadin view, wires it to the data access layer, and verifies the full implementation compiles
  5. Consults the Vaadin, jOOQ, and JavaDocs MCP servers for current API documentation
  6. Does not create test classes — use /browserless-test and /playwright-test for that

Input: Use case ID as argument Output: Vaadin view + jOOQ data access classes Plugin: aiup-vaadin-jooq

/browserless-test — Vaadin Browserless Server-Side Tests (recommended, in aiup-vaadin-jooq)

Purpose: Creates server-side unit tests for Vaadin views using the official Vaadin Browserless framework (com.vaadin:browserless-test-junit6) — no browser, no WebDriver, no servlet container. Browserless Testing is free and open source under Apache 2.0 since Vaadin 25.1.

Usage:

/browserless-test UC-001

What it does:

  1. Reads the use case spec to derive the test scenarios
  2. Generates a JUnit 5 test class extending SpringBrowserlessTest (annotated @SpringBootTest)
  3. Uses the $() / $view() component query API for lookups and the test() wrapper for interactions
  4. Seeds test data via Flyway migrations under src/test/resources/db/migration — never via Mockito, services, or DSLContext
  5. Cleans up only test-created data in @AfterEach (does not wipe the schema)
  6. Preserves transaction boundaries — tests are not annotated @Transactional
  7. Reads component state through the component's Java API; reserves test(...) for actions

Input: Use case ID as argument Output: Browserless test class under src/test/java Plugin: aiup-vaadin-jooq

/karibu-test — Karibu Server-Side Tests (legacy — no longer recommended, in aiup-vaadin-jooq)

Use /browserless-test instead for new projects. Since Vaadin 25.1 the official Browserless Testing framework is free and open source under Apache 2.0, making the community Karibu Testing library redundant. This skill is retained for existing codebases that already use Karibu.

Purpose: Creates Karibu unit tests for Vaadin views — server-side tests that exercise the full Vaadin component tree without launching a browser.

Usage:

/karibu-test UC-001

What it does:

  1. Reads the use case spec to derive the test scenarios
  2. Generates a JUnit 5 test class using Karibu helpers (LocatorJ, GridKt, NotificationsKt, ConfirmDialogKt)
  3. Seeds test data via Flyway migrations under src/test/resources/db/migration — never via Mockito, services, or DSLContext
  4. Cleans up only test-created data in @AfterEach (does not wipe the schema)
  5. Preserves transaction boundaries — tests are not annotated @Transactional
  6. Uses the KaribuTesting MCP server for documentation and code generation

Input: Use case ID as argument Output: Karibu test class under src/test/java Plugin: aiup-vaadin-jooq

/playwright-test — Playwright Tests (in aiup-vaadin-jooq)

Purpose: Creates browser-based tests for Vaadin views using Playwright with the Drama Finder library for type-safe, accessibility-first element wrappers. Covers two test types, dispatched on the argument:

Input Artifact Test type
UC-* Use case specification (docs/use_cases/UC-*.md) Use case test — integration tests for one view, grouped in @Nested classes
TC-* Test case document (docs/test_cases/TC-*.md) Test case journey — one end-to-end test walking the whole flow across views

Usage:

/playwright-test UC-001     # integration tests for one view
/playwright-test TC-001     # end-to-end journey test across views

What it does:

  1. Decides the test type from the argument (UC-* vs TC-*), then reads the matching document to derive the tests
  2. Generates a test extending AbstractBasePlaywrightIT (handles browser lifecycle, page creation, and Vaadin synchronization automatically)
  3. For a use case: covers the main success scenario, alternative flows, and validation rules in @Nested classes
  4. For a test case journey: implements the whole Flow as a single @Test method with one private step method per flow row, navigating between views through the UI like a user would — one test class per test case
  5. Names the test class after the artifact: UC<id><PascalCaseName>IT for use cases (e.g. UC-001-create-reservation.md → UC001CreateReservationIT) and TC<id><PascalCaseName>IT for test cases (e.g. TC-001-customer-onboarding.md → TC001CustomerOnboardingIT)
  6. Writes black-box tests against the running application (default: http://localhost:8080) — does not consult the implementation
  7. Uses Drama Finder element wrappers exclusively — never raw Playwright locators, XPath, Thread.sleep(), or page.waitForTimeout()
  8. Reuses existing test data from Flyway migrations; cleans up only test-created data in @AfterEach
  9. Looks up Drama Finder method signatures via the bundled API reference, falling back to the JavaDocs MCP server

Input: Use case ID (UC-*) or test case ID (TC-*) as argument Output: Playwright test under src/test/java — UC*IT.java for use case tests, TC*IT.java for journeys Plugin: aiup-vaadin-jooq

/flyway-migration — Flyway Database Migrations (in aiup-angular-jpa)

Purpose: Generates versioned Flyway migration scripts (V*.sql) that create the schema described in docs/entity_model.md, using snake_case column names so they match Hibernate's default JPA field mapping. Detects whether the backend is a flat single module or a hexagonal multi-module Maven reactor and places migrations in the correct location (the persistence-adapter module's db/migration directory for a hexagonal layout).

Usage:

/flyway-migration

Input: docs/entity_model.md Output: backend/src/main/resources/db/migration/V*.sql (flat) or <persistence-adapter-module>/src/main/resources/db/migration/V*.sql (hexagonal) Plugin: aiup-angular-jpa

/implement — Use Case Implementation (in aiup-angular-jpa)

Purpose: Implements a use case end-to-end across a Spring Boot backend — flat single-module or hexagonal multi-module (ports and adapters enforced at the Maven-module boundary) — and an Angular frontend.

Usage:

/implement UC-001

What it does:

  1. Reads the use case specification from docs/use_cases/ and the entity model from docs/entity_model.md
  2. Detects the backend's module layout before writing any backend code, and follows whichever asymmetric hexagonal conventions the project already established (e.g. outbound-only ports, no inbound use-case interface) rather than "fixing" them into textbook full hexagonal
  3. Implements the backend per the detected pattern — pure domain record, service, outbound port, DTO, JPA adapter, and REST controller for hexagonal; entity/repository/service/controller for flat — verifying compilation at each module boundary
  4. Implements the frontend: a standalone Angular component using signal() state and a hand-written HttpClient service with a colocated *.model.ts
  5. Does not create test classes — use /spring-boot-test, /vitest-test, and /playwright-test for that

Input: Use case ID as argument Output: Backend classes per detected pattern, plus an Angular page/component Plugin: aiup-angular-jpa

/spring-boot-test — Spring Boot Backend Tests (Angular/JPA)

Purpose: Creates Spring Boot tests for REST controllers and Spring Data JPA repositories, detecting and following whichever integration-test convention a project already uses — RestAssured + Testcontainers, or MockMvc — rather than assuming one.

Usage:

/spring-boot-test UC-001

What it does:

  1. Reads the use case spec to derive the test scenarios
  2. Detects the existing test convention; if neither exists yet, defaults to RestAssured + Testcontainers (exercises the real HTTP wire format and a real Postgres container, matching the convention this plugin was built from)
  3. For a hexagonal layout, places integration tests in the composition-root module and any @DataJpaTest in the persistence-adapter module (the only one with the JPA classpath)
  4. Never mocks the repository/service layer with Mockito

Input: Use case ID as argument Output: Spring Boot test class under the composition-root (hexagonal) or backend/src/test/java (flat) Plugin: aiup-angular-jpa

/vitest-test — Angular Component Tests (in aiup-angular-jpa)

Purpose: Creates Vitest component tests for Angular views using Angular's own testing idioms — TestBed, ComponentFixture, and HttpTestingController — rather than porting React Testing Library patterns.

Usage:

/vitest-test UC-001

What it does:

  1. Reads the use case spec to derive the test scenarios
  2. Generates a test file named UC-XXX-<slug>.spec.ts, colocated with the component/service, with a top-level describe block named after the use case
  3. Mocks HTTP calls via provideHttpClientTesting()/HttpTestingController, verified with httpMock.verify()
  4. Reads state via signal getters and asserts on rendered DOM via native Angular queries

Input: Use case ID as argument Output: Vitest spec file colocated with the component (frontend/src/**/*.spec.ts) Plugin: aiup-angular-jpa

/playwright-test — Playwright End-to-End Tests (in aiup-angular-jpa)

Purpose: Creates browser-based end-to-end tests for Angular views using Playwright's native accessibility-first locators — no wrapper library needed. Since these projects typically have no existing e2e tooling, the skill checks for a conflicting framework (Cypress, Protractor) before scaffolding Playwright.

Usage:

/playwright-test UC-001

What it does:

  1. Reads the use case spec to derive the test scenarios
  2. Checks for an existing e2e framework before assuming Playwright is unclaimed
  3. Generates a test file grouping scenarios in a test.describe block per use case, tagged { tag: "@UC-XXX" }
  4. Writes black-box tests against the running Angular dev server (default: http://localhost:4200) and backend
  5. Uses Playwright's own locators exclusively — never CSS selectors, XPath, or waitForTimeout()

Input: Use case ID as argument Output: Playwright test file under frontend/tests/e2e/ Plugin: aiup-angular-jpa

Project Structure

After running the full workflow for a project, your tree will look like this:

your-project/
├── docs/
│   ├── vision.md                         ← you maintain this
│   ├── requirements.md                   ← produced by /requirements
│   ├── entity_model.md                   ← produced by /entity-model
│   ├── use_cases.puml                    ← produced by /use-case-diagram
│   ├── use_cases/                        ← produced by /use-case-spec
│   │   ├── UC-001-create-reservation.md
│   │   ├── UC-002-cancel-reservation.md
│   │   └── ...
│   └── test_cases/                       ← produced by /test-case — journeys for /playwright-test TC-*
│       └── TC-001-book-and-check-in.md
├── src/
│   ├── main/
│   │   ├── java/                         ← produced by /implement
│   │   └── resources/
│   │       └── db/migration/             ← produced by /flyway-migration
│   │           ├── V001__create_room_type_table.sql
│   │           └── ...
│   └── test/
│       ├── java/                         ← produced by /browserless-test, /playwright-test
│       └── resources/
│           └── db/migration/             ← test data seeds
└── CLAUDE.md

The tree above shows the Vaadin/jOOQ shape. aiup-angular-jpa supports that same flat split or a hexagonal multi-module Maven reactor (domain/business/postgres/api/app), detected automatically. See each plugin's own README for its exact project-structure tree.

Recommended CLAUDE.md

Create a CLAUDE.md at your project root. Claude loads this automatically at the start of every session:

# Project Context

This project follows the AI Unified Process. Read `docs/vision.md`, `docs/requirements.md`,
and `docs/entity_model.md` for product context before making decisions.

## AIUP Workflow

1. `/requirements`        → derives `docs/requirements.md` from `docs/vision.md`
2. `/entity-model`        → derives `docs/entity_model.md` from requirements
3. `/use-case-diagram`    → produces `docs/use_cases.puml`
4. `/use-case-spec UC-XX` → produces `docs/use_cases/UC-XX-*.md`
5. `/flyway-migration`    → produces `src/main/resources/db/migration/V*.sql`
6. `/implement UC-XX`     → implements the use case (Vaadin + jOOQ)
7. `/browserless-test UC-XX` → server-side unit tests (recommended, free since Vaadin 25.1)
8. `/playwright-test UC-XX` → browser-based integration tests (or `TC-XX` for an end-to-end journey)

Never skip the spec for a use case before implementing it.
Always read the entity model before writing data access code.

Recommended docs/vision.md Structure

The /requirements skill relies heavily on this file. Include at minimum:

# Vision: <Product Name>

## Mission

<One paragraph on what this product does and the problem it solves.>

## Target Users

- <Primary user role and what they need from the system>
- <Secondary user roles>

## Goals

- <Measurable business or product goals>

## Scope

- In scope: <high-level capabilities>
- Out of scope: <explicit non-goals>

## Constraints

- <Regulatory, technical, organizational constraints>

Tips

Maintain traceability. Every entity should map to at least one functional requirement; every use case should trace to one or more FRs; every test should reference a use case ID. The skills produce stable IDs (FR-001, UC-001, …) — keep them.

Edit between steps. The intermediate documents (requirements.md, entity_model.md, use_cases.puml) are designed to be reviewed and corrected by hand. Do not skip the review.

Re-run upstream skills when requirements change. If a new functional requirement appears, re-run /entity-model and /use-case-diagram so the downstream artifacts stay consistent. Re-running is cheap; fixing inconsistencies later is not.

Keep aiup-core even on non-Vaadin stacks. The methodology skills are stack-agnostic — only the construction-phase skills are tied to Vaadin/jOOQ. You can pair aiup-core with any implementation toolchain.

Commit docs/ to version control. The vision, requirements, entity model, and use case specs are your project's institutional memory — they explain why the code is the way it is, which is invaluable for onboarding and debugging months later.

Learn More

Visit unifiedprocess.ai for the full methodology.

Key Concepts

Marketplace

A marketplace is a curated repository that hosts and distributes multiple Claude Code plugins. It acts as a central hub where plugins can be discovered, installed, and managed. When you add a marketplace to Claude Code, you gain access to all the plugins it contains.

Plugin

A plugin is a self-contained extension that adds new capabilities to Claude Code. Each plugin can include skills, agents, hooks, and MCP servers. Plugins are technology-specific and encapsulate everything needed to work with a particular tech stack or methodology.

Skill

A skill is a specialized behavior defined in a SKILL.md file. Skills can be invoked explicitly as slash commands ( e.g., /requirements) or triggered automatically by Claude when it recognizes a matching task. Skills are namespaced by their plugin (e.g., aiup-core:requirements).

MCP Server

An MCP (Model Context Protocol) server is an external service that provides Claude with access to specialized tools and documentation. The plugins in this marketplace ship with the following servers:

Server Plugin Description
context7 aiup-core General library documentation lookup
Vaadin aiup-vaadin-jooq Vaadin component and framework documentation
KaribuTesting aiup-vaadin-jooq Karibu testing framework documentation
jOOQ aiup-vaadin-jooq jOOQ DSL and code generation reference
JavaDocs aiup-vaadin-jooq, aiup-angular-jpa Java API documentation lookup
Playwright aiup-vaadin-jooq, aiup-angular-jpa Browser automation for integration tests

About

No description, website, or topics provided.

Resources

Readme

License

Apache-2.0 license
Activity
Custom properties

Stars

98 stars

Watchers

2 watching

Forks

19 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages