Format code using the projects formatter

Writes end-to-end browser tests in TypeScript with @playwright/test for any web UI that is not Vaadin (Angular, Next.js, other client-side frameworks alike): a use case test (UC-XXX) with one test per scenario, or a test case journey (TC-XXX) that walks the whole Flow table across views with one test.step per row. Locates elements by role, label, and text against the running application and cleans up only the data the test created. Use when the user asks to "write Playwright tests", "create e2e tests", "test in the browser", "automate a test case", "test a user journey", "automate TC-001", or mentions end-to-end, browser, or UI integration tests. Normally run by /use-case-test (or /test-case-implement for a TC-*) as the E2E layer of a project whose docs/architecture/stack.md names Playwright; it can also be run directly. For a Vaadin UI use /vaadin-e2e-test.

Demo skill one used to verify global vs project install behavior across agents

Demo skill two used to verify global vs project install behavior across agents

Interview stakeholders to clarify ambiguous or underspecified requirements before writing code. Use when receiving a new task, feature request, or bug report that lacks clear acceptance criteria. Produces clarified requirements ready for spec authoring. Common triggers: "new feature", "build me", "implement", "add support for", or any task where requirements are vague or incomplete.

Verify that implementation and tests remain synchronized with specs after code changes. Use when code has been generated or modified from specs, after implementation is complete, or when reviewing a PR that touches spec-covered code. Reports mismatched targets, broken test links, and undocumented behavioral changes. Common triggers: "verify the spec", "check spec alignment", "are specs up to date", or after completing implementation work.

Create or update .spec.md files from clarified requirements. Use when requirements have been gathered and confirmed, and specs need to be written or updated before implementation begins. Produces well-structured spec files with frontmatter, requirements, and test links. Common triggers: "write the spec", "update the spec", "create a spec for", or after requirement-gathering completes.

Scan a project for practice gaps — missing domains, weak implementations, and new technology areas. Use when starting a new project, joining an existing codebase, beginning a major feature (3+ new files), or when the PreToolUse gate hook blocks a write. Produces a structured gap report that drives skill-search and downstream skills.

Generate project-level quality standards in CLAUDE.md from installed proactive skills. The quality block is the single biggest lever for code quality (4x improvement in experiments). Use after skill-classifier runs, when the skill set changes, or when the user asks "update my quality standards", "what standards should I follow".

Compare your code against installed proactive skill checklists and fix gaps. Use after committing, after completing a feature, before submitting a PR, or whenever you want to verify your code meets quality standards. Can be triggered by a post-commit hook, a periodic check, or a direct request like "review your code", "check quality", "did you follow the skills".

Create or update a CONSTITUTION.md that defines project governance — establishes coding standards, quality gates, TDD policy, review requirements, and non-negotiable development principles with versioned amendment tracking. Use when defining project rules, setting up coding standards, establishing quality gates, configuring TDD requirements, or creating non-negotiable development principles.

Create a feature specification from a natural language description — generates user stories with Given/When/Then scenarios, functional requirements (FR-XXX), success criteria, and a quality checklist. Use when starting a new feature, writing a PRD, defining user stories, capturing acceptance criteria, or documenting requirements for a product idea.

Generate a technical design document from a feature spec — selects frameworks, defines data models, produces API contracts, and creates a dependency-ordered implementation strategy. Use when planning how to build a feature, writing a technical design doc, choosing libraries, defining database schemas, or setting up Tessl tiles for runtime library knowledge.

Implements the UI layer of a use case (UC-XXX) with Hilla: a @BrowserCallable endpoint that delegates to the service layer, and a React/TypeScript view under src/main/frontend/views/ with file-based routing, Vaadin React components, useForm validation from the generated models, and the messages the specification states. The endpoint is Hilla's API and belongs to this layer; it holds no business logic. Use when the user asks to "build the Hilla view for UC-001", "implement the UI layer with Hilla", "create a React view for Vaadin", "create a @BrowserCallable endpoint", or mentions Hilla, TSX views, file-based routing, or useForm in a project that combines layer plugins. Normally run by /use-case-implement after the service layer; it can be run directly. For server-side Java views use /vaadin-flow-ui.

Writes the UI layer tests of a use case (UC-XXX) for Hilla React views with Vitest in browser mode and React Testing Library, with the generated endpoint clients mocked by vi.spyOn — no server, no database. Covers what the actor sees: rendering, form input and useForm validation, the calls the view makes to the endpoint, and the messages the specification states for every outcome and alternative flow. Each suite is UC-XXX-<slug>.test.tsx with describe('UC-XXX: <name>'). Use when the user asks to "test the Hilla view of UC-001", "write Vitest tests for a Hilla view", "test a React view for Vaadin", "test the UI layer", or mentions Hilla testing, endpoint mocking, or TSX view tests in a project that combines layer plugins. Normally run by /use-case-test after the service tests; it can be run directly. Also writes a Java test of the endpoint's access annotation and EndpointException messages. The business rules are tested by the integration layer's test skill.

Writes the end-to-end tests of a Vaadin application (Flow or Hilla) with Playwright for Java and the Drama Finder library's type-safe, accessibility-first element wrappers, against the running application. Two kinds: a use case test (UC-XXX) — one class UC<id><Name>IT with @Nested groups per alternative flow — and a test case journey (TC-XXX) — one class TC<id><Name>IT, annotated @TestCase(id, useCases) with the use cases its Flow links, walking the whole Flow table across views in a single test with a // Step <n>: comment per row. Use when the user asks to "write Playwright tests", "write E2E tests for UC-001", "automate TC-001", "test the user journey in the browser", "write IT tests", or mentions end-to-end, browser tests, Playwright for Vaadin, or Drama Finder in a project that combines layer plugins. Normally run by /use-case-test as the last layer, and the only one /test-case-implement TC-XXX runs; it can be run directly.

Creates Vaadin Browserless server-side unit tests for Vaadin views covering navigation, component interactions, form validation, grid operations, and notifications. Use when the user asks to "write Browserless tests", "write Vaadin UI unit tests", "unit test a Vaadin view without a browser", "create view tests with the official Vaadin testing framework", or mentions Browserless testing, SpringBrowserlessTest, browserless-test-junit6, UI Unit Testing, or server-side Vaadin testing.

Audits an already-written use case (UC-XXX) or test case (TC-XXX) against its specification and reports a coverage matrix: which main success scenario steps, alternative flows, business rules, preconditions, and postconditions have code and tests behind them, which are still open, and which code or tests have drifted away from the specification. Use when the user asks to "check coverage", "run a coverage check", "is UC-001 fully implemented", "is UC-001 completely tested", "audit the use case", "show me the coverage matrix", "do a traceability check", "what is still missing for UC-001", or "can I set the status to Tested". This is specification coverage, not line coverage from a coverage report. It reports only — it writes no code, no tests, and no files. When the user wants the gaps closed rather than listed, use /implement, /implement-hilla, /browserless-test, /hilla-test, /karibu-test, or /playwright-test instead.

Creates versioned Flyway database migration scripts (V*.sql) with sequences, tables, constraints, and foreign keys from the entity model. Use when the user asks to "create a migration", "generate SQL scripts", "set up database tables", "write a Flyway migration", or mentions schema migration, DB migration, database versioning, or SQL migration files.

Use when the user asks to write unit tests, generate a test suite, or migrate/convert Jest or Vitest tests to Themis in Node.js/TypeScript repos. Produces Themis-native tests, runs validation commands, and applies Themis migration workflows.

Builds the persistence layer of a use case (UC-XXX) with jOOQ: one @Repository per aggregate with an injected DSLContext, type-safe queries against the classes jOOQ generates from the Flyway migrations, projections into Java records with Records.mapping, MULTISET for nested collections, paging and dynamic filters, optimistic locking when the entity has a version, and UC-XXX BR-YYY markers on the query conditions that enforce a business rule. Transactions stay with the service layer. Hands the repository method signatures and record types to the service layer. Normally run by /use-case-implement after the migration layer; can be run directly. Use when the user asks to "write the jOOQ repository", "implement the data access for UC-001", "add a jOOQ query", "map the result into a record", "set up jOOQ code generation", or mentions jOOQ, DSLContext, Records.mapping, multiset, or a repository in a project that combines layer plugins.

Writes the persistence layer tests of a use case (UC-XXX) for jOOQ repositories: integration tests against a real database (Testcontainers PostgreSQL or the project's database) with @SpringBootTest or @JooqTest, test data from Flyway test migrations, expected values from the specification and the test data, classes named UC<id><Name>RepositoryTest and every method annotated @UseCase. Tests only queries with logic of their own — filters, joins, projections, MULTISET, paging, optimistic locking — not what the integration layer's tests already cover. /use-case-test runs it only to reconcile existing tests, for queries the integration layer cannot reach, or when the persistence layer is named; can be run directly. Use when the user asks to "test the jOOQ repository", "write repository tests for UC-001", "test this query against the database", or mentions jOOQ repository tests, @JooqTest, DSLContext tests, or Testcontainers tests of the data access in a project that combines layer plugins.

Builds the client layer of a use case (UC-XXX) in a Spring Boot application: for every external system its Secondary Actors line names and docs/architecture/stack.md maps under External systems, an outbound port in the business module and an adapter that calls the system as its contract says — an OpenAPI operation through RestClient or an @HttpExchange interface, an AsyncAPI channel through a Kafka or AMQP producer. The adapter maps the provider's DTOs to domain records, so no provider type crosses the port, and turns the alternative flows the system causes (rejection, timeout, unavailable) into domain exceptions; it decides no retry policy alone. Use when the user asks to "call the payment provider", "integrate an external API", "write a REST client", "build the outbound adapter", or mentions RestClient, @HttpExchange, an external system as secondary actor, or a provider's OpenAPI or AsyncAPI file in a project that combines layer plugins. Normally run by /use-case-implement before the service layer.

Writes the client layer tests of a use case (UC-XXX) in a Spring Boot application: for each external system the use case calls, adapter tests against a stub of the provider's contract — MockRestServiceServer or WireMock for an OpenAPI operation, the broker's test setup for an AsyncAPI channel — that check the request on the wire, the mapping to domain records, and every alternative flow the system causes (rejection, timeout, unavailable); plus a reusable in-memory fake of the outbound port that the service, API, and UI tests put in place of the real adapter, so no test reaches the real system. Classes are named <System>ClientTest and every method carries @UseCase. Use when the user asks to "test the REST client", "test the payment provider adapter", "stub the external system", "write WireMock tests", or mentions MockRestServiceServer, WireMock, a fake of an outbound port, or contract-based client tests in a project that combines layer plugins. Run by /use-case-test before the integration layer.

Implements the REST API layer of a use case (UC-XXX) in a Spring Boot application: @RestController endpoints on top of the service layer, request and response DTO records, @Valid input validation, error mapping to RFC 9457 Problem Details with a @RestControllerAdvice, a status code per alternative flow, and paging. Takes the base path and contract style from the API contract section of docs/architecture/stack.md, and builds an operation the use case's **API:** line links in an agreed OpenAPI contract exactly as written; holds no business rule the service does not enforce. Use when the user asks to "build the REST API", "create an endpoint", "expose the use case over HTTP", "add a controller", "map errors to Problem Details", or mentions @RestController, @RequestMapping, DTOs, ProblemDetail, RFC 9457, status codes, or a JSON contract for a separate client such as Angular. Normally run by /use-case-implement after the service layer; it can also be run directly.

Read a deterministic vehicle summary for the morning brief or an owner request: proven overnight unplugged observations, today's measured drive shortfall, positional tire warnings and supported current vehicle warnings. Triggers: 'vehicle morning brief', 'car issues today', 'Tesla brief', 'машины утром'. Cached reads only; no vehicle wake or controls.

Inspect calendar-aware charging status, estimate measured Tesla energy and departure charge, or explicitly run the enrolled native tomorrow-drive charge poll. Triggers: 'charge for tomorrow drives', 'charging automation status', 'estimate Tesla charging stops', 'will my car have enough charge'.

Reads and controls the owner's Tesla vehicles through the Tessie REST API using deterministic scripts: list vehicles, check the allowlist, read battery/charging/climate/locks/tires/firmware/drives and authorized drivers from cache without waking the car, and send confirmed controls (lock, unlock, climate, charging, charge limit, share destination, flash, drive tags). Triggers: 'is the car locked', 'where is the car', 'who can drive the car', 'list Tesla drivers', 'tesla battery', 'tire pressure', 'lock the tesla', 'unlock the tesla', 'start climate', 'charge limit', 'send address to the car', 'tag my drives', 'tessie', 'my vehicles'.

Generates bUnit component tests for Blazor components (.razor): renders the page, fills and submits its forms, asserts the rendered markup and the validation and error messages the use case states, and replaces the handlers and services it injects with test doubles, one test per scenario and business rule tagged with [UseCase]. Use when the user asks to "write bUnit tests", "test a Blazor component", "test the Razor page of UC-001", "create UI tests for Blazor", or mentions bUnit or xUnit rendering tests. Backend tests are /dotnet-test, browser tests /playwright-test.

Generates C# backend unit and integration tests for EF Core DbContext repositories, domain services, and vertical slice handlers using xUnit or NUnit against SQLite in-memory or Testcontainers databases, one test per scenario and business rule, each tagged with [UseCase]. Use when the user asks to "write backend tests for C#", "write .NET tests for this handler", "test ef core context", "write integration tests for dotnet", or mentions xUnit or NUnit handler tests. Blazor component tests are /bunit-test, browser tests /playwright-test.

Builds the data layer of a C# / .NET project from docs/entity_model.md with Entity Framework Core: generates the entity classes, writes IEntityTypeConfiguration Fluent API mappings (table names, decimal precision, enum conversions, foreign keys, unique indexes, binary columns), registers them in the DbContext, and adds a native C# migration with dotnet ef migrations add. Use when the user asks to "create an EF Core migration", "add ef migration", "update the schema with ef core", "map the entities in the DbContext", "generate a db migration for .net", or mentions EF Core, DbContext, Fluent API, or dotnet ef in a Blazor .NET project.

Audits an already-written use case (UC-XXX) or test case (TC-XXX) against its specification and reports a coverage matrix: which main success scenario steps, alternative flows, business rules, preconditions, and postconditions have code and tests behind them, which are still open, and which code or tests have drifted away from the specification. Use when the user asks to "check coverage", "run a coverage check", "is UC-001 fully implemented", "is UC-001 completely tested", "audit the use case", "show me the coverage matrix", "do a traceability check", "what is still missing for UC-001", or "can I set the status to Tested". This is specification coverage, not line coverage from a coverage report. It reports only — it writes no code, no tests, and no files. When the user wants the gaps closed rather than listed, use /implement, /spring-boot-test, /vitest-test, or /playwright-test instead.

Creates versioned Flyway database migration scripts (V*.sql) with sequences, tables, constraints, and foreign keys from the entity model. Use when the user asks to "create a migration", "generate SQL scripts", "set up database tables", "write a Flyway migration", or mentions schema migration, DB migration, database versioning, or SQL migration files.

Implements use cases across a Spring Boot + Spring Data JPA backend (flat single-module or hexagonal/ports-and-adapters multi-module) and an Angular frontend wired to that API. Use when the user asks to "implement a use case", "build the API", "create a REST endpoint", "write the data access layer", "build the Angular page/component", or mentions Spring Boot, JPA/Hibernate entities, hexagonal architecture, ports and adapters, or an Angular frontend calling a Java backend.

Stress-test the primary review with an additional independent reviewer that generates its own findings, compares reviewer conclusions, and identifies issues the primary reviewer may have missed. Use when performing a second opinion or double-check review on a pull request, for medium or high risk PRs, when authoring was heavily AI-assisted, when primary reviewer confidence is low, when findings conflict, or when you need to verify findings with a cross-model or same-model challenger. Supports same-model and cross-model configurations for fair comparison.

Turn many candidate findings from reviewers and verifiers into a small, decision-useful set. Deduplicates, ranks, and suppresses weak findings to consolidate review results into a prioritized, actionable list with severity ratings and merged confidence scores. Use when you need to merge findings, consolidate feedback, prioritize issues, or summarize review output after review passes are complete and before human handoff. Trigger phrases: "consolidate review results", "merge findings", "deduplicate feedback", "prioritize issues from review", "summarize reviewer output". The evidence threshold is the filter — not an arbitrary cap.

Provide an independent critique of a pull request (PR) using a clean reviewer context, identifying bugs, security issues, code quality problems, API misuse, and missing test coverage. Use when performing a code review or pull request review after an evidence pack has been built, for green or yellow risk lane PRs, or as part of a full pipeline for red risk lane PRs. Produces candidate findings (covering correctness, security, and architectural concerns) for downstream synthesis — not final verdicts. Operates as a critic, not a co-author. Common triggers: "review this PR", "code review feedback", "fresh review", "independent review".

Implements the persistence layer of a use case (UC-XXX) with Spring Data JPA and Hibernate: @Entity classes mapped onto the Flyway schema (ddl-auto=validate, never create or update), Spring Data JpaRepository interfaces, derived and @Query queries, interface and record projections, attribute converters, fetch joins and entity graphs against N+1 selects, and @Version optimistic locking. Detects a flat single-module or a hexagonal multi-module backend; in the hexagonal case it writes the persistence adapter and the outbound port it implements. No Lombok. Use when the user asks to "write the JPA entities", "create the repository for UC-001", "implement the persistence layer", "map the table to an entity", "fix the N+1 query", or mentions Spring Data JPA, Hibernate, @Entity, JpaRepository, or a persistence adapter. Normally run by /use-case-implement as the Persistence layer; it can also be run directly.

Writes the persistence tests of a use case (UC-XXX) for Spring Data JPA: @DataJpaTest classes against a real database in a Testcontainers container (never H2 unless the project already tests on it), test data from Flyway test migrations, one UC<id><Name>RepositoryTest class per use case with @UseCase annotations. Tests only queries with logic of their own — filters, joins, projections, paging, fetch joins, custom @Query and Specification queries, attribute converters — and says so when the use case has none. In a hexagonal backend it tests through the persistence adapter in the adapter module. Use when the user asks to "test the repository", "write a @DataJpaTest", "test the JPA query of UC-001", "write persistence tests", or mentions DataJpaTest, repository tests, or Testcontainers for Spring Data JPA. /use-case-test runs it only to reconcile existing tests, for queries the integration layer cannot reach, or when the persistence layer is named; it can also be run directly.

Workflow for a ticket that touches real source code (anything that is not purely documentation). Use when a ticket changes code, or when you cannot tell whether it is docs or code (default to this). Covers tests-first gating, implementation, running the full suite, PR, Copilot review, and merge-on-clean-review.

Workflow for a documentation-only ticket — one that changes only the README, files under docs/, any .md file, or a plain text/typo fix, with no source-code changes. Covers the branch, commit, push, PR, human-review, and merge steps.

Add a new Java Flight Recorder event to a TamboUI module following project conventions — `dev.tamboui.AREA.THING` naming, `enabled()` guards, static `commit(...)` helper, and `compileOnly(libs.jfr.polyfill)` for Java 8 modules. Use when the user says "add a JFR event", "trace X with JFR", "instrument Y for flight recorder", or "emit a JFR event for Z".

Build a log-style or chat-style scrollable pane in a TamboUI Toolkit app — `ListElement` configured with no selection highlight, sticky scroll, scrollbar, mouse-wheel capture, focus chain integration, and a pre-wrap helper for long content. Use when the user says "build a log pane", "add a chat pane", "make a scrollable list", "trace pane that auto-scrolls", "tail-style output", or asks how to display many lines of streamed text in a TUI.

Wire keyboard and mouse focus across multiple panes in a TamboUI Toolkit app — assign stable ids, set the initial focus in `onStart()`, and add a visible focused-pane border via `focusManager.focusedId()`. Use when the user says "add multi-pane focus", "set initial focus on the input", "highlight the focused pane", "tab between panes", "make the prompt focused by default", or asks how to manage focus across panels.