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.

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.

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.

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.

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.

Creates Drizzle ORM schema definitions and generated SQL migrations for PostgreSQL from the entity model. Use when the user asks to "create a migration", "generate SQL", "set up database tables", "update the schema", or mentions Drizzle, drizzle-kit, pg-core, schema.ts, or database versioning for a NestJS project.

Implements use cases across a NestJS backend with Drizzle ORM over PostgreSQL and a Next.js App Router 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 page", or mentions NestJS modules, controllers, providers, Drizzle queries, repositories, or a Next.js frontend calling a NestJS backend.

Creates NestJS backend tests with Vitest — unit specs with stubbed repositories, and Supertest end-to-end specs that boot the application against a real PostgreSQL database in Testcontainers. Use when the user asks to "write backend tests", "test the API", "write an e2e test", "test the endpoint", or mentions Supertest, Testcontainers, NestJS testing, or Vitest for a NestJS project.

Generates micro Flutter/Dart UI components (atoms/molecules) following Atomic Design patterns. Uses StatelessWidget for atoms and HookConsumerWidget for molecules, including form validation classes and auto-generated widget tests with mocktail mocks. Use when the user asks to create small Flutter UI components such as buttons, text fields, inputs, cards, or reusable widgets following Atomic Design principles, or when they need a Flutter atom, molecule, or micro-UI component with Riverpod integration.

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.

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.

Scaffolds a complete A2A agent specifically configured for Gemini Enterprise compatibility, including the JSON-RPC root path and a health check.

Use when the user asks to run E2E tests, verify a web page, generate tests for an app, prove destructive actions are blocked, check if a UI element is visible, fill out a form, or drive a browser with natural language. Returns per-step results with safety classifications, policy decisions, DOM diffs, structured page context, and a signed audit trail.

Use when the user proposes — or the agent detects — a deviation from constitutional defaults that requires an Architecture Decision Record. Triggered by proposals to extract microservices, drop foreign keys, denormalize without measured evidence, store transactional truth in Neo4j, skip Row Level Security, skip the transactional outbox, run destructive migrations, use database-per-service, or any explicit override of a constitutional principle. Drafts a structured ADR with context, decision, consequences, alternatives rejected, migration path, validation criteria, and constitutional sections affected — and refuses to proceed with the underlying work until the ADR is at least Proposed status.

Use when designing or reviewing database architecture for high-demand multi-tenant commerce platforms — including PostgreSQL schema design, foreign keys, indexes, JSONB usage, multi-tenant isolation with Row Level Security, transactional outbox, Neo4j GraphRAG projections, event sourcing decisions, audit logging, partitioning, expand/contract migrations, and product/inventory/order modeling for restaurants, boutiques, drugstores, retailers, distributors, grocery, hardware, or appliance businesses. Triggered by any request to design tables, design schemas, create migrations, model products/variants/inventory/orders/payments, choose between monolith and microservices, choose between PostgreSQL and Neo4j as source of truth, model multi-tenant data, design event flows, or review an ER diagram.

Use when reviewing or designing how Neo4j and GraphRAG interact with PostgreSQL transactional truth — including any feature involving recommendations, semantic product search, ingredient relationships, substitution suggestions, complementary products, AI-assisted discovery, vector search combined with graph traversal, or any proposal that puts orders, inventory, payments, prices, or tenant access rules into Neo4j. Evaluates architectural proposals for data boundary violations, identifies sync pattern errors between Neo4j and PostgreSQL, produces structured design review feedback with severity-ranked findings, counter-proposals with Mermaid diagrams, eventing changes, and re-projection plans. Triggered by mentions of GraphRAG, Neo4j, knowledge graph, recommendations engine, semantic search, vector + graph hybrid search, AI product discovery, or any design that crosses the PostgreSQL ↔ Neo4j boundary.

Writes end-to-end browser tests in TypeScript with @playwright/test for any web UI that is not Vaadin (Angular today, 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.

Use when the user asks to log work, record what was done, or save task progress. Creates a structured markdown task log in `agent-logs/` with validation, waivers, and a final gates summary.

Use when the user asks you to implement a feature, fix a bug, or complete a repository task end-to-end (from scoping through code changes, validation, and final gate summary).

Use when `.tf` or `.tfvars` files have been edited, added, or removed and you need to verify that the code changes produce the intended Terraform plan before the task is considered complete. Runs `terraform plan` in `examples/test_app` and cross-checks the result against the change set you expected your edits to cause. This is a gate: do not declare a Terraform task done without passing it.

Configures private Realtime channels with RLS-backed authorization on the realtime.messages table. Enforces tenant-scoped Presence and Broadcast security. Use when implementing private realtime channels, realtime authorization, presence security, broadcast security, or securing the realtime messages table.

Generates Postgres Auth Hook that injects tenant_id and serialized permissions into JWT app_metadata using jsonb_set. Use when implementing RBAC, multi-tenant JWT claims, custom access token hooks, or permission injection into Supabase auth tokens.

Configures pgsodium Vault extension for API key and secret storage. Creates SECURITY DEFINER functions assigned to service_role for secure access. Eliminates hardcoded secrets. Use when storing API keys, managing secrets in Supabase, implementing pgsodium Vault, or replacing hardcoded credentials with Vault references.

Creates RLS policies enforcing tenant_id isolation on shared-schema tables. Verifies ALTER TABLE ENABLE ROW LEVEL SECURITY before policy creation. Requires tenant_id column and custom-access-token-hook JWT claims. Use when implementing multi-tenant data isolation, tenant-safe queries, shared schema RLS, or tenant_id policy creation.

Finds open CFPs relevant to Baruch across Java/AI/developer conferences and maintains persistent CFP state (sent/dismissed/remind) in cfp-state.json. Use when Baruch asks about upcoming conferences, call for papers, speaking opportunities, CFP deadlines, or where to submit a talk proposal.

Follow up with people Baruch met at a conference: from his list of names and conversation notes (text or voice), find each person's real address, draft one short email each in his voice, and post each as a one-tap «Отправить» card; offer a calendar hold only where a meeting was actually agreed. Use for "follow up with people I met", "conference contacts", or a post-event list.

Cadence wrapper that runs check-cfps on its own schedule: refresh open CFP data, apply Sessionize verification, update cfp-state.json, emit an observable-silence cursor marker. Triggers: 'cfp sync', 'sync cfps', 'nightly cfp sync', 'refresh cfps nightly'.

now

Summarize URLs or files with the summarize CLI (web, PDFs, images, audio, YouTube).