Configures NotificationClient handlers, implements async dispatch workflows, and handles DispatchError failures for the pidge v3 notification library in async Python services. Use when working with pidge, pidge v3, pidge notifications, NotificationClient, async notifications, or pidge integration — including setting up API keys, dispatching messages, and handling delivery errors.

Write, review, and refactor Java lambdas, method references, and functional-interface callbacks (Function, Predicate, Supplier, Consumer, Comparator, BiFunction) so they stay readable and behavior-preserving. Use whenever Java code creates or changes a callback passed to a stream, Optional, Map, CompletableFuture, or listener API; when a cleanup or review touches identity lambdas (x returning x), block or multi-line lambdas, method references, suppliers, or side-effecting callbacks; or when the user asks to make Java code cleaner or more functional, even if they never say "lambda". Do not use for stream or Optional semantics themselves, and do not use it to force functional style where a plain loop or branch is clearer.

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.

One-thread-per-device async controller for rate-limited IoT APIs with min-interval throttle, stability filter, and send-latest semantics. Use when a real-time producer (camera loop, sensor feed, event stream) drives a cloud or LAN IoT device that can't keep up with per-frame updates, or when you see flicker / HTTP 429 errors from hammering an actuator.

Renders a segmented progress bar that fills bottom-up with a red/yellow/green gradient — the thermometer pattern users expect, not top-down list order. Use when the user asks for a thermometer chart, vertical progress bar, gauge, meter, status indicator, temperature indicator, RAG status bar, or any color-coded level display where fill direction matters.

Discretise your target values so the debounce controller's stability filter can commit. A floating-point target from a noisy producer will never hold for 2 consecutive ticks — the filter blocks every send and the actuator stays dark. Use when wiring a continuous producer signal (confidence score, sensor reading) into a debounced controller, or debugging "I set_target() but _apply() never fires".

Reference material for writing Rego/OPA policies in a specific domain — Kubernetes admission control, Terraform/CloudFormation infrastructure-as-code validation, HTTP API authorization (request body validation, rate limiting), RBAC/ABAC access control models, metadata annotations, or Regal linter compliance by rule category. Load this when rules.md's general Rego style rules aren't enough and you need worked examples or domain-specific patterns for one of these areas.

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.

Open and warm up a cv2.VideoCapture reliably, probe for real (non-black) frames before starting the main loop, and handle macOS index enumeration quirks. Use when a VideoCapture call succeeds but returns black/stale frames, when switching between built-in and USB webcams, or when the first ~5 seconds of a pipeline produce zero face detections.

Run expensive per-frame inference (face recognition, emotion classification, ViT embeddings) at a fraction of the capture rate so the camera loop stays responsive. Use when designing a vision pipeline that combines high-rate capture (30fps+) with heavy per-frame work (dlib, ViT, DeepFace) and you don't need every frame to be inferred.

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.

Review the surface of a Kotlin API you're designing or exposing — a function, a class, a module, or a published library — against the concerns that govern good API design: simplicity, readability, consistency, predictability, debuggability, testability, and (for published surfaces) backward compatibility, multiplatform, and documentation. Use when the user is designing or reviewing an API — phrases like "review this API," "is this API idiomatic," "design this interface," "review my public API," "will this break binary compatibility," "API design check," or when changing a type that other modules or external consumers depend on. This is the design-and-review counterpart to the always-on idiom rules: those govern how to write a line of Kotlin, this governs how to shape and expose an API.

Convert JUnit-style test classes (`@Test` methods, `assertEquals`, `assertThrows`) to idiomatic Kotest specs (`DescribeSpec` / `BehaviorSpec`, `shouldBe`, `shouldThrow`). Maps assertions, rewrites imports, preserves test intent, then verifies the conversion by delegating to `scripts/verify-no-junit-assertions.sh`. Use when the user wants to migrate a JUnit test file to Kotest, when a test file mixes JUnit and Kotest assertions, or when a new contributor writes JUnit-style assertions in a Kotest project.

Replace java.util.Optional usage (Optional.of, Optional.empty, Optional.ofNullable, orElse, ifPresent, etc.) with idiomatic Kotlin nullable types using the question-mark suffix and the safe-call, elvis, and let operators. Strips Java's Optional workaround out of Kotlin code where the language has a better answer. Use when the user asks to "remove Optional," "kotlinify nullables," "strip Optional wrappers," or shows code that wraps nullable values in Optional for no benefit.

Open and warm up a JavaCV OpenCVFrameGrabber reliably on macOS, probe for real (non-black) frames before starting the main loop, and skip virtual cameras (Insta360 Link, Snap, OBS, Continuity Camera) that hijack low indices. Use when an OpenCVFrameGrabber call succeeds but returns black/stale frames, when switching between built-in and USB webcams, or when the first ~5 seconds of a pipeline produce zero face detections.

Run expensive per-frame inference (face recognition, emotion classification, ViT) at a fraction of the capture rate so the producer loop stays at 30 fps. Includes the 4× downscale pattern for Haar face detection, persisted-overlay technique for skipped frames, and Flow.sample() vs manual modulo approaches. Use when designing a vision pipeline that combines high-rate capture (30 fps+) with heavy per-frame work and you don't need every frame to be inferred.

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.

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.

Orchestrate sub-agents across Claude Code AND GitHub Copilot. Covers what inherits vs what doesn't on each platform, how to pass skills explicitly, and the echo-skills validation handshake. Use when spawning child agents, delegating tasks, building multi-agent pipelines, or troubleshooting why a sub-agent doesn't have access to expected skills or context.

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".

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.

Scaffold the good-oss-citizen contribution gate into a consumer repository: a `pull_request_target` GitHub Actions check that fails any pull request whose description lacks a contribution declaration — an "AI Disclosure" section or an explicit "no AI assistance" statement — plus the vendored detection script, a PR template, and the tessl.json dependency entry. The gate enforces an outcome (AI use is disclosed) on the PR side, where it cannot be bypassed; it does not, and cannot, prove a tool ran. Use when a maintainer wants to add, install, set up, scaffold, enable, or wire up a contribution gate / a PR check that requires good-oss-citizen or AI-use disclosure before contributing.

Runs a structured 10-check pre-submission checklist against an open-source contribution before the contributor opens a pull request. Use when the user has written code for an open-source project and needs to prepare a PR, submit a contribution, or verify readiness. Triggers on "submit a PR", "open a pull request", "prepare the contribution", "ready to merge", "check my pull request". IMPORTANT — run this AFTER code is written but BEFORE submission. Checks: AI policy compliance and disclosure (including voluntary disclosure when no policy exists), diff size and focus, PR template, code style, commit conventions, tests, changelog and metadata, legal requirements (DCO/CLA), agent artifacts, slop detector patterns, and human ownership verification.

Analyzes project contribution guidelines, identifies the right venue (pull request, issue, discussion, RFC/KEP/DEP), checks issue metadata (claims, assignments, labels), searches for prior rejected attempts, and drafts proposals formatted to project templates. Use when the user wants to contribute to an open-source project, fix a bug, submit a PR, improve or refactor code, asks where to submit a change, or needs help choosing between PR/issue/discussion/RFC. Triggers on "fix this issue", "submit a PR", "refactor this", "improve this code", "open a pull request". IMPORTANT — run this AFTER recon and BEFORE writing code to verify the right venue and check for prior attempts.

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.

Build terminal chat user interfaces with TUI4J, including message rendering, input handling, scrollable history, state management, and REST API integration. Use when creating a TUI chat client, terminal-based AI chat interface, styling terminal layouts with Lipgloss, or wrapping a REST API with an interactive terminal UI using the Elm Architecture pattern.

Generates bUnit component unit and integration tests for Blazor components (.razor). Use when the user asks to "write bUnit tests", "test Blazor component", "create UI test for Blazor", or mentions bUnit, Blazor component testing, or xUnit rendering tests.

Generates C# backend unit and integration tests for EF Core DbContext repositories, domain services, and vertical slice handlers using xUnit / NUnit. Use when the user asks to "write unit tests for C#", "test ef core context", "write integration tests for dotnet", or mentions xUnit backend tests.

Generates Entity Framework Core (EF Core) database migrations for C# / .NET projects based on the entity model specification in docs/entity_model.md. Use when the user asks to "create database migration", "add ef migration", "update schema with ef core", "generate db migration for .net", or mentions EF Core, DbContext, or database migrations in C#.