Move every app reference from an old Hubitat device onto a new one — via Settings → Swap Device where possible, a virtual-device bridge or parking slot where the swap list blocks it, and a guided manual re-select where neither works. Use when the user wants to swap, migrate, replace, or move a device's references to a different device, re-home a device to a different hub over Hub Mesh, or asks why a device does not appear in the Swap Device list.

Safely remove a Hubitat device — enumerate where it's used, warn about the blast radius before deleting, verify references cleared after, and re-wire them onto a replacement device. Use when the user wants to remove, delete, retire, or replace a device, or asks what a device is used by before deleting it.

Fire an ordered list of Hubitat devices with a timed hold on each, so you can walk the property and bind each observation to a device id — which lamp is `Kitchen 3`, which shade is `Office Left`, which valve is irrigation zone 7. Use when the user wants to map which physical thing a device controls, identify which zone/lamp/shade/valve is which, run a set of devices one at a time in sequence, or fire devices on a timer for field verification.

Update Z-Wave device firmware on a Hubitat hub via the native zwaveJS updater — discover installed versions, find vendor-latest firmware, stage it, and batch-flash safely with a radio-hang watchdog. Use when the user wants to update/flash device firmware, check which devices are behind on firmware, or fix a device whose issue a firmware update addresses.

Manage the hubs.json config that records how to reach each Hubitat hub by IP for code operations. Actions — init a config, add a hub, set the default hub, remove a hub, list hubs. Use when the user wants to configure, register, add, or list Hubitat hubs for deploy/pull/debug.

Run the Hubitat sandbox linter on app or driver Groovy and judge each finding — real defect vs. false positive — before the code goes near a hub. Use when the user wants to lint, check, or validate Hubitat code, or automatically before deploying.

Use the hub's first-party AI (MCP) Connector Integration to read hub state and drive devices over its local MCP endpoint — connect with the bearer token, discover the live tool surface, prefer read-only tools, gate sensitive actions, and verify the mutation. Use when the user wants to control or query a Hubitat hub through its MCP server / AI connector, or asks whether an operation should go through MCP or the hub_* scripts.

Diagnose Hubitat Z-Wave and Zigbee network problems — ghost/failed nodes, packet errors, weak routes, dead or unjoined Zigbee devices, devices that stopped responding to commands, a broken hub-mesh link, an unhealthy mesh. Use when the user wants to check mesh health, find ghost nodes, debug a flaky/slow/dead Z-Wave or Zigbee device, or figure out why the radio network misbehaves.

Generate a correct Hubitat app or driver skeleton from declared capabilities, with the required lifecycle callbacks, subscription/schedule idioms, and logging conventions wired in. Use when starting a new Hubitat app or driver, or when the user asks to create/scaffold/bootstrap Hubitat Groovy code.

Onboard one or more Hubitat sensors with verification at each step — pair, confirm the built-in driver auto-selected, name by function and position, raise event retention, read the real adjustable preferences, share to the mesh and confirm the mirror, add to inactivity monitoring, acceptance-test, and reconcile the inventory. Use when the user wants to onboard, install, add, or set up sensors (soil probes, contact/motion/temperature/energy sensors) on a hub, or roll out a sensor fleet.

Set up and run offline unit tests for a Hubitat app or driver — load the script under biocomp/hubitat_ci, mock the platform executor, and assert on sendEvent/log/parse output off-hub. Use when the user wants to test, unit-test, mock, or add CI for Hubitat Groovy code.

Generate quality checklists that validate requirements completeness, clarity, and consistency — produces scored checklist items linked to specific spec sections (FR-XXX, SC-XXX). Use when reviewing a spec for gaps, doing a requirements review, verifying PRD quality, auditing user stories and acceptance criteria, or gating before implementation.

Generate Gherkin .feature files from requirements before implementation — produces executable BDD scenarios with traceability tags, computes assertion integrity hashes, and locks acceptance criteria for test-driven development. Use when writing tests first, doing TDD, creating test cases from a spec, locking acceptance criteria, or setting up red-green-refactor with hash-verified assertions.

Generate dependency-ordered task breakdown from plan and specification. Use when breaking features into implementable tasks, planning sprints, or creating work items with parallel markers.

Validate cross-artifact consistency — checks that every spec requirement traces to tasks, plan tech stack matches task file paths, and constitution principles are satisfied across all artifacts. Use when running a consistency check, verifying requirements traceability, detecting conflicts between design docs, or auditing alignment before implementation begins.

Execute the implementation plan by coding each task from tasks.md — writes source files, runs tests, verifies assertion integrity, and validates output against constitutional principles. Use when ready to build a feature from a tasks.md plan, start coding against an Intent Integrity Kit implementation plan, develop from the task list, resume a partially completed implementation, or run the implement phase of the iikit workflow.

Convert tasks from tasks.md into GitHub Issues with labels and dependencies. Use when exporting work items to GitHub, setting up project boards, or assigning tasks to team members.

Report a bug against an existing feature — creates a structured bugs.md record, generates fix tasks in tasks.md, and optionally imports from or creates GitHub issues. Use when fixing a bug, reporting a defect, importing a GitHub issue into the workflow, or triaging an error without running the full specification process.

Resolve ambiguities in any project artifact — auto-detects the most recent artifact (spec, plan, checklist, testify, tasks, or constitution), asks targeted questions with option tables, and writes answers back into the artifact's Clarifications section. Use when requirements are unclear, a plan has trade-off gaps, checklist thresholds feel wrong, test scenarios are imprecise, task dependencies seem off, or constitution principles are vague.

Initialize an IIKit (Intent Integrity Kit) project, uninit (remove IIKit scaffolding before `tessl uninstall`), check IIKit feature progress, select the active IIKit feature, and display the IIKit workflow command reference. Use when starting a new IIKit project, running IIKit init or setup, uninstalling/removing/uninit-ing IIKit before running `tessl uninstall`, checking IIKit status, switching between IIKit features, looking up IIKit available commands and phases, or asking for help with the IIKit workflow.

Creates Playwright browser-based end-to-end tests for Angular views using Playwright's native accessibility-first locators (getByRole, getByLabelText, getByText). Covers two test types: tests for a single use case (UC-*) and end-to-end journey tests for a test case (TC-*) spanning multiple use cases. Use when the user asks to "write Playwright tests", "create e2e tests", "write integration tests", "test in the browser", "automate a test case", "test a user journey", or mentions end-to-end testing, browser tests, or UI integration tests for this stack. Also trigger when the user references a use case (UC-*) or a test case (TC-*) and asks for Playwright or E2E tests.

Creates Spring Boot tests for REST controllers and Spring Data JPA repositories. Defaults to MockMvcTester and RestTestClient + Testcontainers for new projects (asking the user to confirm on the very first backend test), but detects and follows whichever convention a project already uses — including legacy MockMvc or RestAssured + Testcontainers — rather than migrating it. Use when the user asks to "write backend tests", "test the REST API", "test the controller", "write a Spring Boot test", "test the JPA repository", or mentions MockMvc, MockMvcTester, RestAssured, RestTestClient, Testcontainers, @SpringBootTest, or server-side Java testing for this stack.

Creates Vitest component tests for Angular views using Angular's own testing idioms — TestBed, ComponentFixture, and HttpTestingController — not React Testing Library patterns. Use when the user asks to "write frontend tests", "test the Angular component", "write a Vitest test", "unit test an Angular page", or mentions TestBed, HttpTestingController, or component testing for this stack.

Creates tests for Hilla use cases on both sides of the browser boundary: Vitest + React Testing Library tests for the React/TypeScript view (with the generated endpoint clients mocked) and Spring Boot integration tests for the @BrowserCallable service behind it. Use when the user asks to "test a Hilla view", "write Hilla tests", "test a React view for Vaadin", "test a @BrowserCallable service", "write Vitest tests for a Hilla app", or mentions Hilla testing, React Testing Library for Vaadin, endpoint mocking, or testing TSX views.

Implements use cases by creating Hilla views — React/TypeScript views with file-based routing calling @BrowserCallable Java services — and jOOQ queries for the data access layer. Use when the user asks to "implement with Hilla", "create a Hilla view", "build a React view for Vaadin", "create a @BrowserCallable endpoint", or mentions Hilla, client-side Vaadin views, file-based routing, TSX views, or React + jOOQ.

Implements use cases by creating Vaadin Flow views, forms, and grids — server-side Java UI — and jOOQ queries for the data access layer. Use when the user asks to "implement a use case", "build the UI", "create a Vaadin view", "write the data access layer", or mentions Vaadin Flow, server-side Java views, jOOQ queries, Java web app, or database-backed UI. For Hilla (React/TypeScript) views use the implement-hilla skill instead.

Creates Karibu server-side unit tests for Vaadin views covering navigation, component interactions, form validation, grid operations, and notifications. Use when the user asks to "write Karibu tests", "unit test a Vaadin view", "test the UI server-side", "create view tests", or mentions Karibu testing, Vaadin unit tests, or server-side UI testing.

Creates Playwright browser-based tests for Vaadin views using the Drama Finder library for type-safe element wrappers with accessibility-first APIs. Covers two test types: integration tests for a single use case (UC-*) and end-to-end journey tests for a test case (TC-*) spanning multiple use cases. Use when the user asks to "write Playwright tests", "create e2e tests", "write integration tests", "test in the browser", "write IT tests", "automate a test case", "test a user journey", or mentions end-to-end testing, browser tests, UI integration tests, Playwright for Vaadin, or Drama Finder. Also trigger when the user references a use case (UC-*) or a test case (TC-*) and asks for Playwright or E2E tests.

Creates Playwright browser-based end-to-end tests for a Next.js frontend running against a live NestJS API: a test.describe per use case (UC-XXX) with a test per scenario, or a journey per test case (TC-XXX) with one test.step per Flow row, tagged @UC-XXX / @TC-XXX, with accessibility-first locators and the application's seed data, wired into the project's playwright.config webServer setup. Use when the user asks to "write Playwright tests", "create e2e tests", "write end-to-end tests for UC-001", "automate TC-001", "test in the browser", or mentions end-to-end testing, browser tests, or a test case (TC-*) to automate.

Creates Vitest component tests for Next.js App Router pages and React components with React Testing Library in jsdom: renders the client component, drives it with user-event, mocks the project's API client module, asserts the rendered content, the messages, and the requests sent to the NestJS API, one describe block per use case (UC-XXX). Use when the user asks to "write frontend tests", "write Vitest tests for the page", "write React unit tests", "test the component", "write an RTL test", or mentions React Testing Library, jsdom, or component testing for a Next.js project. Browser tests against the running stack are /playwright-test.

Bootstrap a new TamboUI Toolkit DSL application — generates a `ToolkitApp` subclass with a working `render()` and a `main` entry point, plus the right Maven/Gradle/JBang dependencies. Use when the user says "create a TamboUI app", "scaffold a TUI", "new tamboui app", "hello world TamboUI", or asks to start a TUI project from scratch.

Add a Toolkit `Element` wrapping an existing TamboUI widget so it gains CSS support, styled sub-components, focus integration, and a Toolkit factory method. Use when the user says "wrap a widget", "add an element for X widget", "make widget Y CSS-aware", "expose widget Z in the DSL", or asks to integrate a custom widget into the Toolkit.

Prepare or cancel event-specific running-late delegation, inspect running-late status, or run its native three-minute poll. Triggers: 'tell them if I am running late', 'approve lateness messages for this event', 'cancel running-late approval', 'running late status'.

Daily vehicle health watch for the Tessie overlay: wakes only when an addressable vehicle has a low unplugged battery, a Tessie credential or API failure, or unreadable state, then tells the owner what was found; otherwise stays silent. Triggers: 'tesla watch', 'vehicle health check', 'tessie watch', 'monitor my Tesla', 'low battery alert'.