Scaffold a new Adobe Commerce app using the aio-commerce-sdk. Creates the base project structure and app.commerce.config file with metadata. Use when the user wants to create a new Commerce app from scratch or initialize a bare Commerce app project. After scaffolding, chains to appbuilder-project-init for Developer Console setup (project, workspace, API subscriptions) when the user wants to deploy. Does not configure extensibility domains — use commerce-app-eventing, commerce-app-webhooks, commerce-app-business-config, commerce-app-admin-ui, or commerce-app-storage for that.

Integrate App Builder Database Storage (@adobe/aio-lib-db) into an Adobe Commerce app and scaffold a runtime action that reads and writes documents. Use when the user wants persistent, queryable storage backing a Commerce app — either from a web action (HTTP-invokable) or from an event/webhook handler. Requires a base app initialized with commerce-app-init.

Add or modify webhook interceptors in an Adobe Commerce app. Use when the user wants to intercept Commerce operations to validate input, append data, or modify behavior — before or after execution. Requires a base app initialized with commerce-app-init.

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.

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.

Review a diff for missed reuse — whether new code should have reused an existing helper, component, schema, route shape, fixture, or local convention instead of reimplementing it. Follows a strict, bounded search budget so it inspects only a few plausible precedent files, never the whole repository. Use as a code-reuse review lens in `tessl change review` or a GitHub Actions review workflow.

Review a change for whether the next person can understand it and change it safely. Use as one lens in a code review run.

Review a change for what happens when there is more of it than expected, and when something it depends on fails. Use as one lens in a code review run.

Review a change for what an adversary could do with it, and for what it exposes about people. Use as one lens in a code review run.

Review a diff for security risks across auth/authz, untrusted input, injection, output encoding, secrets, crypto, sensitive logging, file and network access, webhooks, and dependency or build-script changes. Use when reviewing a pull request, diff, or code change for security issues or vulnerabilities, as a security review lens in `tessl change review` or a GitHub Actions review workflow. Reports high-confidence, file-anchored findings and complements scanners (CodeQL, Snyk, Dependabot) rather than duplicating them.

Review a diff for test risk — changed behaviour without meaningful tests, bug fixes without a regression test, async/error/edge branches left uncovered, and brittle tests that assert implementation trivia instead of behaviour. Use as a test-coverage review lens in `tessl change review` or a GitHub Actions review workflow. Reports high-confidence, file-anchored findings.

On a byAir precheck wake event, reconciles the operator's managed calendar events (boarding block, adopted byAir flight event, Reclaim travel-block cleanup, switched-away teardown) and composes a user-facing flight notification — delay, gate change, cancellation, boarding, connection risk, inbound-delay, time-to-leave, baggage carousel, day-before check, or arrival logistics. Also configures the plugin (verify credentials, set home base). Use when a tracked-flight wake event needs a notification, or when setting up or diagnosing flight-assist. Triggers - "check flight-assist env", "diagnose flight-assist", "set flight-assist home base", "set home address", "configure flight-assist", "flight delay notification", "gate change notification", "cancellation notification", "boarding alert", "time to leave alert", "inbound delay notification", "baggage carousel", "arrival logistics", "day before sanity check", "flight removed upstream", "connection at risk", "tight connection alert", "reconcile calendar".

Travel-data refresh bundle: TripIt → Reclaim timezone sync, refresh travel-schedule.json from the TripIt iCal feed with a two-tier Gmail freshness probe, rebuild travel-db.json, log newly-appeared trips to daily memory, then check upcoming trips for booking gaps. Runs daily; precheck-gated on travel-db.json freshness. Triggers: 'sync trips', 'sync travel', 'update travel data', 'pull trip info', 'refresh travel schedule', 'rebuild travel db', 'check my bookings'.

Adaptive scheduler for the TripIt/byAir refresh of active-flights.json. Precheck-gated to keep byAir polling responsive on flight days and idle between travel windows. Use when active-flights.json isn't updating, byAir polling cadence isn't matching flight density, troubleshooting flight tracking / flight notifications / flight status updates / travel schedule refresh, or setting up flight-assist on a new install. The gate predicate and threshold constants live in precheck.py.

Shared travel-domain library bundle for the nanoclaw-travel plugin. Hosts the cross-skill Python modules trip_origin (TripIt-over-home position/anchor resolution) and airport_lead (clearance / post-arrival buffer policy) so flight-assist and the drive engine import one source of truth instead of duplicating them. Not a user workflow — background code the other skills load at runtime; never invoke directly.