What problem does it solve? Building gesture, button, EMG, motion, and geolocation features for Meta smart glasses is risky because native DAT APIs, Web App browser APIs, and phone sensors have different capability boundaries, and official sources sometimes conflict. This Skill keeps each signal source, permission model, and evidence level explicit so you never claim a capability the target hardware has not proven. ## Core Features & Use Cases - Signal routing: Classify every input by surface (native DAT Display, Ray-Ban Display Web App, glasses sensor, or phone sensor) before writing code, using runtime capability metadata instead of consumer device labels. - Normalized event contract: Define a bounded InputEvent model with source, action, session epoch, timestamp, and permission state, plus lifecycle rules for debounce, stale-event rejection, and teardown. - Evidence-driven verification: Produce a capability/permission matrix and eight evidence rows (INP-SOURCE-01 through INP-RELEASE-01) separating mock, browser, connected, physical, and release proof. - Use Case: When adding D-pad navigation and motion sensing to a Ray-Ban Display Web App, use this Skill to gate browser sensor APIs behind secure-context and permission checks, define a phone fallback, and script a named physical-device test run. ## Quick Start Use the meta-wearables-input-sensors skill to design the input handling for my Meta Display app that needs button taps, EMG activation, and geolocation with a phone fallback.
